Dropping one extra = from declarations to make them less divergent from Cpp1 syntax

[msadeqhe]

After introducing the new terser syntax for lambdas, I think sooner or later, this topic will be discussed by someone else (maybe by the author of Cpp2 @hsutter himself). BTW sooner is better than later. So let's discuss it please.

Currently, we use = to declare stuff (types, namespaces, functions and variables), and we use == to alias stuff.

cls1: <T> type = {/*...*/} // Type definition
cls2: <T> type == cls1<T>; // Type alias

nms1: namespace = {/*...*/} // Namespace definition
nms2: namespace == nms1;    // Namespace alias

fnc1: (x) -> cls1<i32> = {/*...*/} // Function definition
fnc2: (x) -> cls1<i32> == fnc1(x); // ERROR: Function alias with explicit signature
fnc3: (x) = {/*...*/}              // Function definition
fnc4: (x) == fnc3(x);              // ERROR: Function alias with explicit signature

var2: cls1<i32> = expr;  // Variable initialization
var3: cls1<i32> == expr; // Variable alias (const&)
var5: = expr;            // Variable initialization
var6: == expr;           // Variable alias (const&)

As you see, the = always followed by : and it doesn't have a special meaning for each declaration. Also the reason of those errors is that intentionally they are not allowed yet. Would it be possible to consider dropping one extra = from them (except for variable declarations)?

cls1: <T> type {/*...*/}  // Type definition
cls2: <T> type = cls1<T>; // Type alias

nms1: namespace {/*...*/} // Namespace definition
nms2: namespace = nms1;   // Namespace alias

fnc1: (x) -> cls1<i32> {/*...*/}  // Function definition
fnc2: (x) -> cls1<i32> = fnc1(x); // OK: Inlined function is function alias
fnc3: (x) {/*...*/}               // Function definition
fnc4: (x) = fnc3(x);              // OK: Inlined function is function alias

var1: cls1<i32> = expr;  // Variable initialization
var2: cls1<i32> == expr; // Variable alias (const&)
var3: = expr;            // Variable initialization
var4: == expr;           // Variable alias (const&)

As you see in this way:

• The concept of inlined function would be unified with function alias. So it leads to reducing concept count.
• Symbol = will have the right meaning in the right place:
  • It means creating an alias in type and namespace declarations.
  • It means creating inlined function in function declarations.
  • It means creating an instance of object in variable declarations.
• The declaration syntax would be more familiar to C++ programmers. It leads to less divergent from Cpp1 syntax which is/was one of the goals of Cppfront. For example compare them:

  // Type declarations
  class X {/*...*/}   // Cpp1
  X: type {/*...*/}   // Cpp2 (this suggestion)
  X: type = {/*...*/} // Cpp2 (current)
  
  // Type aliases
  using Y = X;  // Cpp1
  Y: type = X;  // Cpp2 (this suggestion)
  Y: type == X; // Cpp2 (current)
  
  // Function declarations
  auto Z  (int  a) -> int {/*...*/}   // Cpp1
       Z: (a: int) -> int {/*...*/}   // Cpp2 (this suggestion)
       Z: (a: int) -> int = {/*...*/} // Cpp2 (current)

• The declaration syntax won't make Cpp2 to favor an indentation-style over others.

  // Cpp2 (current)
  fnc: (x) -> i32 = {
      //...
  }
  // It looks strange because `=` is before `{`.
  fnc: (x) -> i32
  = {
      //...
  }
  // It looks strange too because the line ends with `=`.
  fnc: (x) -> i32 =
  {
      //...
  }
  
  // Cpp2 (this suggestion)
  fnc: (x) -> i32 {
      //...
  }
  // It looks normal and familiar.
  fnc: (x) -> i32
  {
      //...
  }

• Dropping the extra = won't harm readability. So it leads to less typing to write Cpp2 programs.
• Symbol == which is inspired from operator== already cannot be used to compare types and namespaces. So it can be the reason to don't use == to create type and namespace aliases, while we can use = as a good candidate for them.

Thanks for your patience.

[msadeqhe]

More explanations

fnc1: (x) -> cls1<i32> {/*...*/}  // Function definition
fnc2: (x) -> cls1<i32> = fnc1(x); // OK: Inlined function is function alias
fnc3: (x) {/*...*/}               // Function definition
fnc4: (x) = fnc3(x);              // OK: Inlined function is function alias

I have to explain that in this example, the default return type with {/*...*/} is void, and the default return type with = /*...*/ is _. That's it. fnc4 is inline, therefore its return type is exposed to callers, and it doesn't harm compile time to investigate its return type.

Additional considerations

You could ignore this part.

Considering == in variable declarations

• Symbol == which is inspired from operator== already cannot be used to compare types and namespaces. So it can be the reason to don't use == to create type and namespace aliases, while we can use = as a good candidate for them.

Variable aliases exist in RAM, so = can be used as the meaning of the requirement to initialize them first, although they are constants. Maybe it's the good time to consider an alternative syntax (something similar to const for them). One possible syntax is like this:

var1: i32 = 10;
var2: const = var1; // Constant variable is variable alias.

BTW this is not a part of my suggestion right now.

[JohelEGP]

fnc2: (x) -> cls1 == fnc1(x); // ERROR: Function alias with explicit signature

That's a constexpr function now.
The grammar comments are outdated:

cppfront/source/parse.h

Lines 8140 to 8143 in 3512ecd

	//G
	//GT ':' function-type '==' expression ';'
	//GT # See commit 63efa6ed21c4d4f4f136a7a73e9f6b2c110c81d7 comment
	//GT # for why I don't see a need to enable this yet

[msadeqhe]

Thanks, so == would mean constexpr for both functions and variables:

// constexpr function
fnc1: (x) -> _ == f(x);

// constexpr variable
var1: _ == value;

And it's compliant with disallowing == for both types and namespaces, because they cannot be constexpr (EDIT: I mean if we consider to keep Cpp2 semantics to be similar to Cpp1 semantics as much as it doesn't hurt Cpp2's goals).

[JohelEGP]

And makes #634 unnecessary.

[msadeqhe]

Concept declaration syntax in Cpp2 from this file is already like this:

arithmetic: <T> concept = std::integral<T> || std::floating_point<T>;

But it looks different from declaraing type and namespace aliases because of = vs ==:

v: <T> type == std::vector<T>;

[JohelEGP]

Yeah, I've been thinking about the asymmetry.
Concepts are definitely a compile-time thing.
So they should use ==,
and rejected with = on the grounds that == is used for compile-time things.

[JohelEGP]

Would you like to open a new issue on this?

[msadeqhe]

IMO I like to open an issue about type and namespace declarations to change them from == to =. 😅

[AbhinavK00]

I don't understand something here, = is used when declaring a new thing while == is used when giving a new name to an already existing thing and it extends to constexpr values are well, it's only at constexpr functions that this rule breaks. Other than that, there's no compile-time/runtime thing between = and ==. While you can definitely think the above concept example as giving a new name to an already existing value, it gets more complicated when requires expressions are inovolved.

[JohelEGP]

There's also the question of consteval: b589f5d#commitcomment-128465809.

[msadeqhe]

By dropping the extra = from declarations, it's possible to make {...} to be visually separated as either block statement or list of items. Therefore as discussed in #637, {...} may mean list initialization in addition to block statement:

// {...} is a block statement.
fnc1: () {...}

// {...} is an initializer list.
fnc2: () -> ret = {...};

Also all control structures can be directly used inside an expression with {...}:

// It's similar to Rust.
// {...} is a block expression, because `if` is placed on the right side of `=` inside an expression.
var1: = 2 + if x < 10 { x } else { x - 10 };

// {...} is a block statement, because `if` is placed stand-alone outside an expression.
var2: = 2;
if x < 10 {
    var2 += x;
}
else {
    var2 += x - 10;
}

And it's consistent with inspect too:

var3: = inspect x < 10 -> bool { is true = x; is _ = x - 10; };

And lambda syntax would be consistent with new terser syntax (as discussed in #793):

var4: = call(: (x) x + 1);
var5: = call(: (x) { print(x); });
var6: = call(: (x) -> i32 { return x + 1; });

But it's a breaking change, considering Cpp2 is in development, and it's not finalized yet.

[msadeqhe]

If Cpp2 will get this syntax:

var1: = 2 + if x < 10 { x } else { x - 10 };

The syntax of list initialization may be changed from {...} to [...] to make it visually distinct from {...} in if-expressions (also other control structures in expressions):

v: std::vector<i32> = [1, 2];

var2: std::vector<i32> = if x < 10 { [1] } else { [1, 2] };

[SebastianTroy]

It also simplifies the meaning of '=' I suppose, to only mean variable assignment/construction, because assigning a function to a name isn't really the same thing unless you're making a function pointer, but then you're actually assigning something so I suppose it makes function pointer assignment slightly harder to mix up with a function with a single statement? Fptr: (x: int, y:int) -> bool = foo&; I forget the reasons for adding the = to function declaration, and I don't dislike it, but if there are good reasons (beyond it saves a character here and there) to remove it then I won't particularly miss it either. On 11 November 2023 07:20:28 Sadeq ***@***.***> wrote: By dropping the extra = from declarations, it's possible to make {...} to be visually separated as either block statement or list of items. Therefore as discussion in #637<#637>, {...} may mean list initialization in addition to block statement: // {...} is a block statement. fnc1: () {...} // {...} is an initializer list. fnc1: () = {...}; Also all control structures can be directly used inside an expression with {...}: // It's similar to Rust. // {...} is a block expression, because `if` is placed on the right side of `=` inside an expression. var1: = 2 + if x < 10 { x } else { x - 10 }; // {...} is a block statement, because `if` is placed stand-alone outside an expression. var2: = 2; if x < 10 { var2 += x; } else { var2 += x - 10; } And it's consistent with inspect too: var3: = inspect x < 10 -> bool { is true = x; is _ = x - 10; }; And lambda syntax would be consistent with new terser syntax (as discussed in #793<#793>): var4: = call(: (x) x + 1); var5: = call(: (x) { print(x); }); var6: = call(: (x) -> i32 { return x + 1; }); But it's a breaking change, considering Cpp2 is in development, and it's not finalized yet. — Reply to this email directly, view it on GitHub<#742 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQJICZGGEX4WLLCLCQTYD4RLTAVCNFSM6AAAAAA5Z2JK2CVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM3TKMZZGIZDA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[msadeqhe]

I've fixed the syntax of fnc2: () = {...}, the return type was missed:

// {...} is a block statement.
fnc1: () {...}

// {...} is an initializer list.
fnc2: () -> ret = {...};

So fnc2 is similar to a variable declaration, and = {...} sets the return value.

[msadeqhe]

I've created issue #824 from our discussion.