[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.

[msadeqhe]

Assignment to Typed Expression:

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

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

// It's equal to:
//      = Type::operator=(out this, B).operator=(something)
C: Type = B: Type = something;
//  (2 + 2): Type = something;
// x++*.f(): Type = something;

// It's equal to:
//      = Type::operator=(out this, something)
D: Type = : Type = something;

It's can be safe to disallow assignment in case 3, because it's rvalue:

// ERROR `B: Type` is rvalue.
C: Type = B: Type = something;

I'm going to categorize them.

They all have a similar syntax but semantically they are different in this way:

1. Variable Declarations
   They are statements.
   • something: Type;
   • something: Type = value;
2. Unnamed Variables
   They are expressions.
   • (: Type = value)
3. Typed Expressions
   They are expressions.
   • (something: Type)
   • (something: Type /*unary postfix operators*/)
   • For example:
     • (something: Type = value)
     • (something: Type++)
     • (something: Type.member...)

Unnamed Variables are a special Typed Expression.

So we can think about it that Unnamed Variables are a special Typed Expression. This is a generalized syntax for both of them:

(something: Type = value)

Unnamed Variables don't have the something part, therefore the variable won't be initialized with something, instead it will be initialized with value, because value is the first assignment, and the first assignment is initialization.

After that, they would be categorized in this way:

1. Variable Declarations
   They are statements.
   • something: Type;
   • something: Type = value;
2. Typed Expressions
   They are expressions.
   • (something: Type)
   • (something: Type /*unary postfix operators*/)
   • For example:
     • (something: Type = value)
     • (something: Type++)
     • (something: Type.member...)
   • (: Type = value) aka Unnamed Variables
   • (: Type) is invalid, because it's an uninitialized variable which is immediately used.

This categorization will reduce concept count.

[msadeqhe]

I'm trying to find a general rule to reduce concept count.

Also Unnamed Functions could be somehow a special Typed Expression if Cpp2 would support issue suggestion #391 titled "Statement-expressions, result vs return". In general it would be possible to have a block statement after assignment operator. Let's look at the syntax of typed expression with function types and assignment in this case:

(something: (args) -> Type = { /*statements*/ })

Unnamed Functions don't need the something part, because the something part is for passing arguments to the function (see next comment), because the function body cannot be before parameter declarations. If we don't write something part, it would be a function object, otherwise it would immediately call the function. So assignment is needed to define function body.

After that, they would be categorized in this way:

1. Variable/Function Declarations
   They are statements.
   • something: Type;
   • something: Type = value;
   • (NEW) something: Type = { /*statements*/ }
2. Typed Expressions
   They are expressions.
   • (something: Type)
   • (something: Type /*unary postfix operators*/)
   • For example:
     • (something: Type = value)
     • (NEW) (something: Type = { /*statements*/ })
     • (something: Type++)
     • (something: Type.member...)
   • (: Type = value) aka Unnamed Variables
   • (NEW) (: (args) -> Type = { /*statements*/ } aka Unnamed Functions
   • (: Type) is invalid, because it's an uninitialized variable which is immediately used.

I have to clarify about the syntax (described above) of typed expressions:

• The type is not restricted. It can be either:
  • a variable type (e.g. Type).
  • or a function type (e.g. (args) -> Type).
• But something cannot be a statement (e.g. { /*statements*/ }).
  • Because Typed Expressions can only be applied to expressions.
• If the type of typed expression is a function type:
  • If it has something, the function would be immediately called (see next comment).
  • It must have an assignment. Because function body must be after parameter declarations.

So this example won't be allowed:

// WRONG! This typed expression applied to a statement block.
{ /*statements*/ }:(args) -> Type

[msadeqhe]

I examined () for type composition within declarations, it seems () is not needed at all within declarations.

<> for grouping types

Currently we use parentheses to group expressions: (1 + 2) * 3. I suggest to use angle brackets <> to group types and make it a syntax sugar to decltype in this way:

2:<N*m> == 2:decltype(2:N * 2:m)
2:<int> == 2:decltype(2:int)

Also it's syntactically possible to use () instead of <> without any conflict, that's based on the rule that typed expressions cannot be a function type (except if they are unnamed functions, hence the left-side of : doesn't exist), becuase function body must be after its signature. So we would have:

a: = 120:A;

// `(A)` is not a function signature, because it's a typed expression.
a: = 120:(A);

// But `(A)` is a function signature, because it's a declaration.
a: (A) = ...

Examples:

2:int == 2:(int)

2:(N*m) == 2:(kg*m2/s2)
1:(J/mol/K) == 1:(m2*kg/s2/mol/K)

1:(J/(mol*K)) == 1:(m2*kg/(s2*mol*K))

a: Type = 0;

2:(decltype(a)*int)

2:((Abc + Xyz)++ * (Abc + Xyz)++)
2:(Abc < Xyz)
2:(Abc > Xyz)

Although () is more readable than <>, but<> always means the same in contrast to ().

So type composition within declarations would be like this:

A: type = { /*declarations*/ }
B: type = { /*declarations*/ }
function: <T> (a: A*T, b: B*T) -> A*B = { /*statements*/ }

X: type = { /*declarations*/ }
variable: <T> X*T = /*value*/;

That's because , has lowest precedence and it's not an operator, it's just a separator. So () should not be used for type composition within declarations.

Briefly, it means that:

• For type composition within declarations, () should not be used around composed type, because () means function type:

  function: <T> (a: A*T, b: B*T) -> A*B = { /*statements*/ }

  Now compare it with type aliases in which the type composition depends on template parameters.
  This doesn't work:

  x: X = (); // OK.
  t: T = (); // ERROR! `T` is a template parameter.
  XT: == decltype(x*t); // No, it doesn't work.
  function: <T> (a: XT, b: XT) -> XT = { /*statements*/ }

  Because in this case, a variable template is needed:

  x: X = (); // OK.
  t: <T> T = (); // OK. `T` is a template parameter.
  XT: <T> == decltype(x*t<T>); // OK, it works.
  function: <T> (a: XT<T>, b: XT<T>) -> XT<T> = { /*statements*/ }

  So type composition within declarations makes the code simpler to write and easier to read when type composition depends on template parameters.
• For type composition within typed expressions, () has to be used around composed type, because operators have lower precenece than :, and typed expressions cannot be function types, therefore () wouldn't conflict with it:

  x: = something:(A*B);

[msadeqhe]

C23 got typeof and typeof_unqual.
IIUC, they'll be C++ when it's rebased on C23.

That's interesting. Also C23 has auto.

decltype would still be used and therefore renaming it could be considered.

I like how Cpp2 already has type keyword, and type(...) could be used to mean decltype(...).

[realgdman]

1:N:m (1 Newton metre)
What does it mean to construct a quantity of metres from Newtons?

I agree that's not intuitive from human-language point too. In cpp2 : generally means is-a, like "f is-a function", and "Newton is-a metre" makes little sense.

[JohelEGP]

1:<N*m> solves that and the $n-1$ constructions of 1:N:m, which translates to m(N(1)).

[msadeqhe]

Yet Another Alternative Solution

What if first we try to fix arg.Type(other_args...) for object construction? I've written the problems of UFCS on types in this comment. If we use (all_args...).Type or expr.Type instead of arg.Type(other_args...), it would be like this:

Abc: type = { /*declarations*/ }

x1: = 1.Abc;   // this suggestion
x2: = 1.Abc(); // in current Cpp2

y1: = (1, 2).Abc; // this suggestion
y2: = (1).Abc(2); // in current Cpp2

z1: = (1, 2, 3).Abc; // this suggestion
z2: = (1).Abc(2, 3); // in current Cpp2

So (all_args...).Type doesn't have the problems of UFCS on types:

• It's not UFCS, because it doesn't have parenthesis after Type as the same as UFCS doesn't work on member variables.
  • So the first parameter this of operator= will not be (all_args...) in (all_args...).Type.
  • It's not inconsistent with UFCS on functions, because it's not UFCS at all.
• It has less possibility than UFCS on types to be overrided by a member.
  • Because most of the time, member variables are not public.

    Abc: type = {
        member: int = 0;
    }
    
    member: type = {
        operator=: (out this, value: Abc) = { /*statements*/ }
    }
    
    main: () = {
        x: Abc = ();
        
        // `member` is a type, because `Abc::member` is not public.
        // It calls the constructor `member::operator=(x)`.
        y: = x.member;
    }

• It complements UFCS.
  • UFCS works on non-member functions and member functions.
    • Member functions will override non-member functions within obj.func(args).

    Abc: type = {
        // It overrides non-member function `func`.
        func: (this) = { /*statements*/ }
    }
    
    Cde: type = {
        // Nothing overrides non-member function `func`.
    }
    
    func: (obj: Abc) = { /*statements*/ }
    func: (obj: Cde) = { /*statements*/ }
    
    main: () = {
        x: Abc = ();
        y: Cde = ();
    
        // It calls member function `func`.
        x.func();
    
        // It calls non-member function `func`.
        y.func();
    }

  • This suggestion works on types and member variables.
    • Member variables will override type constructions within (args).Type or expr.Type.

    Abc: type = {
        // It overrides type construction.
        vari: int = 0;
    }
    
    Cde: type = {
        // Nothing overrides type construction.
    }
    
    vari: type = {
        operator=: (out this, value: Abc) = { /*statements*/ }
        operator=: (out this, value: Cde) = { /*statements*/ }
    }
    
    main: () = {
        x: Abc = ();
        y: Cde = ();
    
        // It gets member variable `vari`.
        a: = x.vari;
    
        // It constructs an instance of `vari`.
        b: = y.vari;
    }

  • It would be possible to add member variables and functions outside type definition (something similar to extension properties and methods).
• All arguments are in one-side, because all of them have the same characteristic to construct the object:

  Abc: type = {
      operator=: (out this, a: int, b: int) = { /*statements*/ }
  }
  
  main: () = {
      // this suggestion
      x: = (1, 2).Abc;
  
      // With UFCS on types, it looks strange.
      y: = (1).Abc(2);
  }

Using . instead of : has the advantage of using () with type composition, because it wouldn't be ambiguous with function types, by the way still <> can be used instead of ():

10.(N*m) == 10 * 1.kg * 1.m2 / 1.s2

// <> can be used instead of ()
10.<N*m> == 10 * 1.kg * 1.m2 / 1.s2

But this alternative solution has a problem (opinion-based). The problem is that if something is a type, 1.something would call the constructor function, but it doesn't have () like other function calls.

[msadeqhe]

Now, if we use (all_args...).Type to create an instance of Type with arguments (all_args...), and if we use parentheses around composed types within typed expressions, and if we don't use anything around composed types within declarations, this is how the code would look like:

// Type composition within declarations:
A: type = { /*statements*/ }
B: type = { /*statements*/ }
function: <T> (a: A*T, b: B*T) -> A*B = { /*statements*/ }

point: type = {
    operator=: (out this, a: A, b: B) = { /*statements*/ }
}

main: () = {
    a: = ().A; // It calls the default constructor.
    b: = 12.B; // It calls the constructor `operator=(out this, 12)`.
    c: = 12.int.B; // Also they can be chained.

    // Type composition within typed expressions:
    x: = 10.(N*m) == 10 * 1.kg * 1.m2 / 1.s2;
    y: = 10.(N*m) == 10.(kg*m2/s2);

    z: = (a, b).point;
}

[JohelEGP]

I don't think that's context-free:

Cpp2 strictly avoids this, and never requires sema to guide parsing. When I say "context-free parsing" this is the primary thing I have in mind... the compiler (and the human) can always parse the current piece of code without getting non-local information from elsewhere.
-- Extract from https://github.com/hsutter/cppfront/wiki/Design-note%3A-Unambiguous-parsing.

x.b is already valid today and means member access.
We'd need to know whether b is a type to know what x.b means.

Even with parentheses, (x).b and (0,1,x).b are valid today.

[msadeqhe]

Yes, it's not context-free, because it's based on UFCS a.Something(args) for types in which Something may be a type or a function. Whereas that syntax is changed to (a, args).Something in which Something may be a type or a variable.

The motivation of this alternative suggestion is that if UFCS a.Something(args) for types is currently acceptable in Cpp2 as a context-free language, (a, args).Something would be acceptable too.

[JohelEGP]

They are not so comparable.
The function call func(arg) and construction type(arg) are very similar, even in Cpp1.
The member access arg.something and construction something(arg) are way more dissimilar.

[msadeqhe]

That's right but something(args) itself is not context-free, of course a.something(args) is not context-free, either. something can be either type or function.

I've to clarify I don't want to say that 1.stuff is better than 1:stuff or 1stuff, it's another alternative suggestion to consider.

[msadeqhe]

From this comment:

I have to correct my suggestion about derived units e.g. <A*B> in previous comment:

• The type of <A * B> is always A.
  • For every arithmetic operator, the type of A op B is always A.
• The type of <A && B> is always bool.
  • For every logical operator, the type of A op B is always bool.
• The type of <A += B> is always A&.
  • For every assignment operator, the type of A op B is always A&.
• But the type of the following operators depend on the signature of their functions:
  • <A*> aka Indirection
  • <A&> aka Address-of
  • <A()> aka Function Call
  • <A[]> aka Subscript

For arithmetic, logical and assignment operators, the type of expression is always known from themselves. So <> is not needed at all to get the type of them. Also <A*>, <A&>, <A()> and <A[]> operations are not useful within derived units.

So simply EXPR:TYPE is enough and EXPR:<TYPE> is not needed.

[JohelEGP]

The type of 1s + 1.0s is their common type, which is the type of 1.0s.

[SebastianTroy]

Surely the same suffix would result in the same type anyway? On 15 June 2023 13:34:39 Johel Ernesto Guerrero Peña ***@***.***> wrote: The type of 1s + 1.0s is their common type, which is the type of 1.0s. — Reply to this email directly, view it on GitHub<#463 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQJWGJE4E3JRTBB5PYTXLL6NVANCNFSM6AAAAAAYJLD2PA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msadeqhe]

What if Cpp2 uses the following syntax for named arguments?

x: = call(name: = "someone", age: int = 20);

It may conflict with this suggestion (EXPR:TYPE).

[msadeqhe]

Thanks. After discussion in #663, @hsutter confirmed Type(args) would stay in Cpp2 for its goodness, so this suggestion to have expr:Type or (args):Type syntax seems redundant now. I close it as outdated.