[SUGGESTION] Typed Expressions; generalized constructors, UDLs, unnamed variables and functions

[msadeqhe]

This is an alternative solution to this issue. If you don't like ...TYPE notation for object construction because of its UDL syntax, this is an alternative solution. In this suggestion, objection construction would use familiar notation EXPR:TYPE (aka Typed Expression) which is similar to how Cpp2 programmers use it within declarations.

Consider EXPR:TYPE as syntactic sugar to (: TYPE = EXPR). For example:

Abc: type;
Xyz: type;
func: (u: int) -> Abc;

a: int = 2;
b: = 2:int;       // (: int = 2)
c: = a:Abc;       // (: Abc = a)
d: = ():Abc;      // Default Constructor
e: = (a + b):Abc; // (: Abc = a + b)
r: = func(a):Abc; // (: Abc = func(a))
s: = func(2):Abc.start():Xyz.value; // Function Chaining
t: = a++:Abc;     // (: Abc = a++)
u: = a:Abc++;     // (: Abc = a)++
x: = 2:int:Abc;   // (: Abc =: int = 2) Constructor Chaining
y: = (2:int + 4:int):Abc; // (: Abc = (: int = 2) + (: int = 4))
z: = ("text", 2:int):Abc; // (: Abc = ("text", (: int = 2)))

Literally if x:int is at the start of a statement or function parameter, it would be a declaration, otherwise it would be a Typed Expression.

Abc: type;

// `x: Abc` is a parameter declaration.
func: (x: Abc) = {}

// `a: int` is a declaration.
a: int = 2;

// `a:Abc` is a Typed Expression, it calls the constructor of `Abc`.
m: = a:Abc;

EXPR:TYPE is similar to ...TYPE suggestion, except with the following advantages:

• It's familiar and similar to declaration syntax in which types are specified in the language.
• It's easier to parse, but ...TYPE would complicate the grammar especially for working within function chaining.
• It doesn't need parentheses for simple expressions with unary postfix operators (e.g. a++:Abc). It depends on operator precedence, and it's left to right.

And this notation has the following disadvantages:

• It requires an extra :. BTW it's opinion based.

I have to explain : within SOMETHING:TYPE is for object construction (as an expression) or declaration (as a statement), but :: within SOMETHING::TYPE is scope resulotion operator for qualified names. They can be combined like 10++ : my::Type. Also after the object is constructored, we can use operator dot or operator() or operator[] or ... to access members from it, e.g. 10:Type.call() or 10:Type[0].

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.

1. It unifies constructors with UDLs. They are semantically the same. Both of them create a new object.
   1. It's useful in generic programming.
   2. It reduces concept count.
      • Novice programmers don't need to learn a distinct concept about UDLs.
      • All types benefit from UDL like syntax. It's not needed to declare UDL for them.
      • It eliminates the need of understanding and learning built-in prefixes and suffixes for literals.
   3. The syntax of calling constructors will be expressive and readable.
2. It distincts constructors from regular function calls. They are semantically different.
   • Constructors:
     • EXPR:TYPE, parentheses are not necessary when EXPR has operators with higher precedence.
     • ():TYPE, it calls the default constructor
     • (args...):TYPE
   • Regular Function Calls:
     • FUNCTION(), it calls a function without arguments
     • FUNCTION(args...)
     • obj.FUNCTION()
     • obj.FUNCTION(args...)
3. They can be chained together, whereas it's not possible with UDLs in Cpp1.
   • Only one UDL can be applied to a literal in Cpp1.
4. Constructors already can be templated, but UDLs cannot be templated.
   • UDL templates are not supported in Cpp1.
5. It removes built-in literal prefixes and suffixes. They are inconsistent and redundant.
   1. They are visually inconsistent.
      • Some of them are prefix.
      • Some of them are suffix.
   2. Their behaviours are inconsistent when the constant of literal exceeds the type as described in this comment.
6. The name to construct a literal and to declare a variable will be consistently the same.
   • It's not needed to declare a new name for literal suffixes.
   • The name of types are like a suffix that will construct an object.
7. They can be applied to literals with qualified name (if they are within namespaces) unlike UDLs which need using statement before they can be applied to literals.
   • That's why UDLs in Cpp1 have to be prefixed with _, thus they will be distinguished from UDLs which are declared in the Cpp1 standard library.
8. Unlike TYPE(args) it doesn't work with UFCS intentionally. UFCS should not work on constructors as described in this comment. Compare:

   // `TYPE(args)` with UFCS on it.
   x: = 10.Type(10, 20);
   
   // `(args):TYPE`
   y: = (10, 10, 20):Type;

Describe alternatives you've considered.

These are alternative solutions:

• [SUGGESTION] Literal suffixes are constructors. #455
• [SUGGESTION] Literal Templates #316 (INACTIVE)
• [SUGGESTION] Multiple suffixes for literals, a revisit of Uniform Function Call Syntax #284 (INACTIVE)

Thanks.

[msadeqhe]

EXPR:TYPE is similar to ...TYPE suggestion, except with the following advantages:

• It's familiar and similar to declaration syntax in which types are specified in the language.
• It's easier to parse, but ...TYPE would complicate the grammar especially for working within function chaining.
• It doesn't need parentheses for simple expressions with unary postfix operators (e.g. a++:Abc). It depends on operator precedence.

And this notation has the following disadvantages:

• It requires an extra :. BTW it's opinion based.

Also this suggestion won't add any new syntax to the language, it uses the existing syntax SOMETHING : TYPE, but as expressions. Currently in Cpp2 we use : TYPE = ... expression to create unnamed variables, but it won't conflict with that because unnamed variables don't have the left side of :, and they have an extra =.

[msadeqhe]

In a nutshell:

• ID : TYPE would be a declaration if it's at the start of a statement or function parameter.
  • We use ID : TYPE to specify the type of a declaration.
• EXPR : TYPE would be a typed expression if it's not at the start of a statement or function parameter.
  • We use EXPR : TYPE to specify the type of an expression.
  • EXPR : TYPE calls the constructor of TYPE with the result of EXPR as the argument.
  • (ARGS) : TYPE calls the constructor with ARGS.
  • () : TYPE calls the default constructor.
• : TYPE = SOMETHING would be an unnamed variable.

[AbhinavK00]

I like the other suggestion better I think. Would this be context-free?

…

On Sun, 21 May 2023, 17:50 Sadeq, ***@***.***> wrote: In a nutshell: - ID : TYPE would be a declaration if it's at the start of a statement. - We use ID : TYPE to specify the type of a declaration. - EXPR : TYPE would be a typed expression if it's not at the start of a statement. - We use EXPR : TYPE to specify the type of an expression. - : TYPE = SOMETHING would be an unnamed variable. — Reply to this email directly, view it on GitHub <#463 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2KJHTTIO3C2EI2JIBJYF7LXHICATANCNFSM6AAAAAAYJLD2PA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msadeqhe]

Thanks. Yes, It would be context-free, because the behaviour of SOMETHING : TYPE is dependent on its placement:

// It's a declaration.
something: Type;

// It's a typed expression.
call(something: Type);

// It's a parameter declaration.
call: (something: Type) = {}

[msadeqhe]

Briefly:

// `A` is a declaration.
A: Type = 0;

// `B` is a declaration.
// `X` is a typed expression.
B: Type = X: Type;

[JohelEGP]

A typed expression can subsume a UDL better than UFCS.

Let's consider the type std::chrono::year:

date := 1970y/January/1; // UDL after `using namespace std::chrono_literals;`
date := 1970.y()/January/1; // UFCS after `using namespace ufcs_literals;` (see next code block).
date := 1970:y/January/1; // Direct construction after `using namespace typed_expr_literals;` (see next code block).
date := 1970:year/January/1; // This suggestion after `using std::chrono::year;`
date := 1970:std::chrono::year/January/1; // Ugly, but possible.

As you can glean from the comments,
a typed expression uses direct construction,
whereas UFCS implies an extra object in-between, the function parameter.

Just switch from having a _literals namespace with Cpp1 UDLs to type aliases.

typed_expr_literals: namespace = {
y: type == std::chrono::year; // Direct construction.
}
ufcs_literals: namespace = {
y: (int i) -> _ = std::chrono::year(i); // Indirect construction through `i`.
}

For an alias template (e.g., to replace the UDLs 1s and 1.0s), compiler support is still in the works:

[JohelEGP]

From our experience at https://github.com/mpusz/units, which has quantity references (e.g., 1 * m for 1 m),
one point against some things that try to replace UDL (e.g., UFCS) vs. UDL
is that bringing a UDL into scope doesn't take up the symbol in the UDL (because it's actual name is operator""𝘴𝘺𝘮𝘣𝘰𝘭).
So, for example, something like using namespace unit_literals; with variables
introduces conflicts, specially when formulas are involved.
From Quantity References vs Unit-specific Aliases:

1. Shadowing issues

   • Quantity References

     References occupy a pool of many short identifiers which sometimes shadow the variables,
     function arguments, or even template parameters provided by the user or other libraries. This
     results in warnings being generated by some compilers. The most restrictive here is MSVC which
     for example emits a warning of shadowing N template parameter for an array size provided
     in a header file with Newton unit included via namespace declaration in the main() program
     function (see experimental_angle <https://github.com/mpusz/units/blob/master/example/references/experimental_angle.cpp>).
     In other cases user is forced to rename its local identifiers to not collide with predefined
     references (see capacitor_time_curve <https://github.com/mpusz/units/blob/master/example/references/capacitor_time_curve.cpp>).

   • Unit-specific Aliases

     As aliases are defined in terms of types rather variables no major shadowing issues were found
     so far. In case of identifiers abiguity it was always possible to disambiguate with more
     namespaces prefixed in front of the alias.

As seen from "Unit-specific Aliases", a typed expression isn't thus affected.
But UFCS, which works on functions (and behave like variables), possibly does.

See also UDLs vs Quantity References for many major pain points against UDLs.
One that applies to UDL and UFCS, but not typed expression:

• 2. UDLs cannot be disambiguated with a namespace name

[JohelEGP]

I expanded on the quote above.
A typed expression isn't actually affected, but UFCS probably is.

Allow me to expand the summary's table:

Feature	Aliases	References	Typed expression	UDLs
Literals and variables support	Yes	Yes	Yes	Literals only
Preserves user provided representation type	Yes	Yes	Yes	No
Explicit control over the representation type	Yes	No	Yes	No
Possibility to resolve ambiguity	Yes	Yes	Yes	No
Readability	Good	Medium	Good	Good
Hard to resolve shadowing issues	No	Yes	No	No
Operators precedence issue	No	Yes	No	No
Controlled verbosity	Yes	No	Yes	No
Easy composition for derived units	No	Yes	Yes	No
Simplified quantity casting	Yes	No	Yes	No
Implementation and standardization effort	Medium	Lowest	Medium	Highest
Compile-time performance	Fastest	Medium	Fastest	Slowest

As you you can see, a typed expression is the best in almost all aspects.
For details on the "feature", please see the linked documentation.

[JohelEGP]

@mpusz You may be interested in looking at this. In particular, the 3 comments above.

[msadeqhe]

@JohelEGP Thanks for explaining about indirect construction of UDL and UFCS, I wasn't aware of it.

From our experience at https://github.com/mpusz/units, which has quantity references (e.g., 1 * m for 1 m), ...

I changed the example to have typed expressions:

// simple numeric operations
static_assert(10:km / 2 == 5:km);

// unit conversions
static_assert(1:h == 3'600:s);
static_assert(1:km + 1:m == 1'001:m);

_s: = 1:s;
kmph:type == decltype(1:km / _s);

// dimension conversions
static_assert(1:km / 1:s == 1'000:m / _s);
static_assert(2:kmph * 2:h == 4:km);
static_assert(2:km / 2:kmph == 1:h);
static_assert(2:m * 3:m == 6:m2);
static_assert(10:km / 5:km == 2);
static_assert(1'000 / 1:s == 1:kHz);

For this to work, I think that unit types may have an extra template parameter to indicate the prefix. For example metre<1'000> is equal to kilometre.

[JohelEGP]

Don't worry. The library has taken care of all that.
In fact, it already has those alias templates!
So if typed expressions made it to Cpp2, that example would compile right away (not on Clang yet).

[JohelEGP]

From commit 0982b8e:

Note that : continues to be pronounces "is a"... e.g., f: () -> int is pronounced as "f is a function returning int," v: vector<int> as "v is a vector<int>", this: Shape as "this object is a Shape."

That works well for named declarations.
What about expressions with :?

Commit 1090a31 also enabled : std::vector = (5,1).
Let's consider it together with 42:seconds.

: std::vector = (5,1) can be pronounced as "the vector $(5, 1)$", and
42:seconds and 42:s can be pronounced as "42 seconds".

[msadeqhe]

Good point. So it would be like to pronounce:

• 42 : second as 42 is a second.
  • the value of 42 is a second type.
• (a + b) : price as (a + b) is a price.
  • the result of (a + b) is a price type.
• ("name", 30) : Person as ("name", 30) is a Person.
  • the argument group ("name", 30) is a Person type.

In general:

• something : name as something is a name.
  • the expression something is a name type.
• : name = something as it is a name assigned from something.
  • it is the unnamed variable.