[SUGGESTION] Multiple suffixes for literals, a revisit of Uniform Function Call Syntax

[msadeqhe]

In our life, every quantity can have multiple suffixes. For example:

• 1 million dollar
• 1 million euro
• 20% of a bottle of water
• 5,000 grams of apples
• 1 hour of worker

In C++1, optional ' may be inserted between the digits of integer and floating-point literals as a separator. Therefore I propose that every suffix optionally may start with ' and mandatory ' must be inserted between them as a separator for multiple suffixes. Now, let's write the code for the above cases:

1'million'dollar
1'million'euro
20'percent'bottle'water
5'000'gram'apple
1'h'worker

Also built-in suffixes optionaly may start with '. They can be uppercase or lowercase. The built-in integer suffixes are L, LL, Z, U, UL, ULL and UZ (if U is provided, it must be the first in C++2, but it can be the last in C++1). The built-in floating-point suffixes are F, L, F16, F32, F64, F128 and BF16 as defined in C++23.

1'ULL
5'000.0'F

Encoding prefixes of character literals and string literals have to be changed to be suffix (similar to C# language), the first suffix have to be without ', because the end of character literals and string literals already have a quote:

'c'u8'symbol
"UTF-8 string view"u8'sv
R"(raw string)"u8's

As an extra feature, boolean literals may have suffixes, but it's really a special case for libraries:

false'news

In addition, we can write user defined suffixes after built-in suffixes:

100'UL'min
1.5'F'ms

Now, the question is what does it have common to uniform function call syntax. To answer this question, the following example is useful:

// In C++1
apple(gram(5'000))

// In C++2 with Uniform Function Call Syntax
// The above expression can be written as the following expression
5'000.gram().apple()

// In my suggestion, we can go further
5'000'gram'apple

So, definitely suffixes are the same as member functions or free functions. We don't need an operator"" to create user defined literals, each member function with the right signature can be used as suffix. Also free functions with the right signature can be used as suffix. For example:

Gram :type = {
    ...

    apple :(this) ->Apple = {
        ...
    }

    ...
}

gram :(value :int) ->Gram = {
    ...
}

x := 5'000'gram'apple;

No, suffixes should never get any extra parameter, it will ruin its purpose of being less verbose (being without parenthesis), and they should not modify this parameter.

Will your feature suggestion improve performance or expressiveness?

Yes, because user defined literals can improve expressivity of the programmer:

// store.sell(orange(box(2)));
a := store.sell(2'box'orange);

// price(water(bottle(2)) + juice(glass(0.5)))
b := price(2'bottle'water + 0.5'glass'juice);

Maybe it improves performance too, because for built-in suffixes the true type of the literal will be sent to the member function call:

hour :(value :float) ->Hour = {
	...
}

x := 1.0'F'hour;

If we rewrite the above example with operator"" in C++1, then the type of value parameter must be long double instead of float, because operator"" only accepts a parameter of type unsigned long long int or long double.

Uniform function call syntax will also improve generic programming for suffixes.

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?

No.

Will your feature suggestion automate or eliminate X% of current C++ guidance literature?

Yes. My feature suggestion will remove unnecessary extra concept operator"", and it will integrate its usage with normal member functions or free functions. Also It improves code readability.

The purpose of suffix notation is for units or quantities, member function notation is for object-style behaviors or states, and free function notation is for computing.

Describe why you've considered this feature request.

Currently I'm trying to suggest a new string literal for C++2. This suggestion will affect my suggestion about string literals. I hope to read your feedbacks here, therefore I can improve it or I should give up.

[msadeqhe]

I've to correct some parts of my suggestion.

We don't need an operator"" to create user defined literals, each member function with the right signature can be used as suffix. Also free functions with the right signature can be used as suffix.

If using free functions for defining user defined literals seems too much radical change (if we consider binary compatibility with C++1), we should keep using operator"" (or in this suggestion should be renamed to operator'), and give up about making it a part of uniform function call syntax, but user defined suffixes don't need to begin with _ (as restricted in C++1), and their parameter can use any built-in type in addition to unsigned long long int and long double in C++1:

operator 'gram :(value :int) = {
// or simply the above line can be defined like this without operator keyword:
// 'gram :(value :int) = {
    ...
}

x := 5'000'gram;

The goal of my suggestion is about to allow multiple suffixes on literals (for example 1.0'F'ms or 1'box'orange), and the prefix of string literals and character literals should be changed to be suffix, in other words, u8"text"s should be changed to "text"u8's.

[AbhinavK00]

Writing ' to use literal suffix seems extra work, what if we just define

operator gram :(value :int)

Why not , instead of '?

[SebastianTroy]

This might be out there, but with unified function call syntax, could we treat literals and built in types the same as user types and call 1.gram() which would be equivalent to gram(1)? Then we don't need to introduce custom operators or new syntax. It would naturally allow chaining too. On 17 March 2023 09:28:00 Abhinav00 ***@***.***> wrote: Writing ' to use literal suffix seems extra work, what if we just define operator gram :(value :int) Why not , instead of '? — Reply to this email directly, view it on GitHub<#284 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQO5VIS7XY43ZSBSOUTW4QVB5ANCNFSM6AAAAAAV5MNURU>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msadeqhe]

Why not , instead of '?

Because , is already a separator for function parameters and lists:

player.buy(2'box'biscuit, 3'000'banana);

[msadeqhe]

This might be out there, but with unified function call syntax, could we treat literals and built in types the same as user types and call 1.gram() which would be equivalent to gram(1)? Then we don't need to introduce custom operators or new syntax. It would naturally allow chaining too.

Yes, you're right. Literals, member functions and free functions do really the same thing, but in a different style (syntax), and they help programmers to convey more expressively the concept of code.

[jcanizales]

Will your feature suggestion eliminate X% of security vulnerabilities of a given kind in current C++ code?
No.

Might! Anything that eases the use of units, indirectly allow the compiler to catch bugs that we all face every so often. Sure, those bugs of ours aren't as glamorous as the space probe that missed Mars because someone wrote code in non-international units. But they might lead to security vulnerabilities.

[hsutter]

Thanks @msadeqhe for the suggestion, and thanks [edit: @jcanizales @SebastianTroy !!] for the UFCS idea.

Well, this turned into a fascinating little detour, and I think I like the result!

[edit: @jcanizales @SebastianTroy !!]'s intriguing point about UFCS worked today already for string literals... for example, the following already worked:

Gram: type = {
    value:     int;
    operator=: (out this, val: int) = { value = val; }
    print:     (this) = std::cout << "(value)$ grams\n";
}

gram: (val: std::string_view) -> Gram
    = :Gram = sv_to_int(val).value; // (*)

main: () = {
    test := "2".gram();
    test.print();   // prints "2 grams"
}

But it didn't already work for integers because "1." and "1.f" were valid floating point literals, so that . couldn't be parsed as starting a UFCS function call.

I say "were" and "couldn't" because I just changed that... I've long disliked that the C floating point literal syntax allowed omitting the 0 (I find omitting it slightly less readable, though admittedly I've taken advantage of it sometimes just because it was conventional and because, well, laziness).

I've now pushed the above commit that:

• requires that floating point literals have at least one digit after the ., so that .0 be written explicitly, which I think is a small improvement in its own right; and
• therefore unlocks general UFCS on numeric literals, which can be useful generally but also for the purpose of this thread.

With the above commit, the following now works too:

Gram: type = {
    value:     int;
    operator=: (out this, val: int) = { value = val; }
    print:     (this) = std::cout << "(value)$ grams\n";
}

gram: (val: int) -> Gram
    = :Gram = val;

main: () = {
    test := 2.gram();
    test.print();   // prints "2 grams"
}

Note this is also safer, because you know right away you parsed a valid... you don't have to do run-time error checking as with the first string_view example in case someone passes a string that doesn't actually contain an integer (or only an integer).

I think this is an interesting path to explore... let me know what you think as you play around with using this style for unit-type literals.

---

(*) see sample implementations at https://stackoverflow.com/questions/56634507/safely-convert-stdstring-view-to-int-like-stoi-or-atoi

[msadeqhe]

Thanks @hsutter. I have a question, will C++2 support User-defined Literals? I've tried to overload operator "" in C++2, but it doesn't generate any C++1 code:

operator ""_w: (v: ulonglong) -> ulonglong = {
    return 0;
}

Does it mean we should use UFCS instead of User-defined Suffixes?

[AbhinavK00]

It's probably a probably with ulonglong, try using u64 instead.

Edit: Still doesn't do anything, so its not about ulonglong. Still, cpp2 has no type named ulonglong.

Edit 2: I was wrong

[msadeqhe]

Yes, u64 doesn't work either. ulonglong is defined in cpp2util.h with the following line:

using ulonglong = unsigned long long;

[hsutter]

will C++2 support User-defined Literals?

For authoring UDLs: I hadn't decided whether or not to support authoring them, and this thread convinces me we should try using UFCS for that first. It's desirable to solve the problem using a more general language feature, if it works well also for this use case, rather than adding a special-purpose language feature.

For consuming existing Cpp1 UDLs: I haven't made any special effort to either support or prevent consuming them, and I generally want things like that to work for compatibility so that Cpp2 can consume existing Cpp1 libraries with high fidelity. I did a quick test using the cppreference UDL page's Coliru example code for UDLs, and it works with main changed to Cpp2:

main: () = {
    x_rad: double = 90.0_deg_to_rad;
    std::cout << std::fixed << x_rad << '\n';

    y: mytype = 123_mytype;
    std::cout << y.m << '\n';

    0x123ABC_print;
    std::cout << "abc"_x2 << '\n';
}

[AbhinavK00]

It's desirable to solve the problem using a more general language feature, if it works well also for this use case, rather than adding a special-purpose language feature.

While I agree with that, if we already have literals in the langauge, why not just go ahead and let users define theirs?
Cpp2 is already going to consume literals defined in standard llibrary so it is only natural for cpp2 to support UDLs.
it's not a new feature, literals already exist and it's just operator overloading.