Let's make object construction context-free.

[msadeqhe]

In Cpp1 Type(args...) is not context-free.

In Cpp2 : Type = (args...) is the equivalent context-free syntax.

So Cpp2 can be totally context-free if it forbids the Cpp1's syntax in its pure mode.

[msadeqhe]

Also UFCS on types is not context-free in Cpp2:

a: = x.Type(y, z); // This

[msadeqhe]

In the following example, although x, y and z have literally the same characteristic here, but they are separated in a wrong way. Consider we would construct a 3D point like this:

// `x` doesn't have any special different meaning here.
p: = x.Point(y, z);

[hsutter]

(I get it, and I thought about this too once, but let me push back on it.)

My answer is "but id(args) and arg.id(moreargs) are context-free" -- in fact, banning them only when id is a type would make it not context-free. Why? Because a rule that asks "is id a type?" requires name lookup -- which means it cannot (*) be a parsing rule, but it would have to be a semantic rule. In fact, that's the main reason Type(args) and arg.id(moreargs) are supported in Cpp2... they Just Work from the context-free parse. (Note that cppfront has no semantic rules based on name lookup to see if something is a type, because it can't do that for Cpp1 types since I deliberately don't parse and compile Cpp1 code in cppfront, that's left to the Cpp1 compiler.)

(*) well, had better not! 😁 see this design note and search for "name lookup"

There are other reasons I actually like Type(args) and arg.Type(moreargs), including anytime we have a syntax that lets functions be called using a common syntax we help generic code -- as long as the meaning isn't divergent of course, but it isn't here: This simply allows a constructor to be called like any function. For example std::cout << "xyzzy".std::string(3); prints xyz. Here's a 1-minute clip from my 2021 CppCon talk about common syntax enabling generic code, which was about the importance of a consistent spelling of is and as for queries and casts, and why consistent spelling has always been a major reason to want UFCS (which Cpp2 has).

And if we specifically want a constructor call, we can express that too with the : syntax.

[msadeqhe]

Thanks. I like your opinion. So I should use the : syntax (in addition to Type(args) syntax) to specifically call the constructor, otherwise I can use function-style syntax (Type(args) or arg.Type(moreargs)) to treat the constructor as a function in generic programming.

[hsutter]

Yes. And, full disclosure, this is something I learned along the way in the past year -- I didn't know that a year ago, and I don't think I expressed it that clearly until this thread. So thanks again!

[SebastianTroy]

This may be a stupid question, but how do you call a constructor or operator= with explicit this at an out parameter, is there just a special case that assumes the left side of the expression is what the 'this' parameter is assigned to? Or are constructors and constructing operator= functions static members of the type returning an instance? On 7 September 2023 21:00:46 Sadeq ***@***.***> wrote: Thanks. I like your opinion. So I should use the : syntax to specially call the constructor, otherwise I can use function-style syntax to treat the constructor as a function in generic programming. — Reply to this email directly, view it on GitHub<#663 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQPXLSZOZTXK4VU746TXZIRWZANCNFSM6AAAAAA4OPSOBE>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[JohelEGP]

Yeah, for out parameters, you assign to it to call operator=.

[SebastianTroy]

So this would be valid? myPtr : *MyType; myObj := MyType(myPtr,...) And this would be valid as well? myObj := MyType(...) Where ... Denotes whatever the construction parameters may be I'm probably missing something here, and certainly messing up the syntax, but I think my question is, if type construction involves some magic where the first out parameter is actually treated like a return parameter instead, doesn't that also require context? On 7 September 2023 21:24:52 Johel Ernesto Guerrero Peña ***@***.***> wrote: Yeah, for out parameters, you assign to it to call operator=. — Reply to this email directly, view it on GitHub<#663 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALUZQIU3X3WZW2JEFI66I3XZIURDANCNFSM6AAAAAA4OPSOBE>. You are receiving this because you commented.Message ID: ***@***.***>

[JohelEGP]

The first one isn't valid.
You might be interested in https://github.com/hsutter/cppfront/wiki/Cpp2:-operator=,-this-&-that#misc-notes.

I'm probably missing something here, and certainly messing up the syntax, but I think my question is, if type construction involves some magic where the first out parameter is actually treated like a return parameter instead, doesn't that also require context?

I think Herb has answer this before.
Now I just need to find the reference.

[hsutter]

To construct via a call to an out parameter you have to say out at the call site on the out argument. See for example mixed-initialization-safety-3.cpp2, where on one branch it constructs x directly using a constructor (x = "xyzzy";), and on the other branch it calls an out parameter of a function and that callee constructs x (fill( out x, "plugh", 40 )). It guarantees initialization-before-use on every path, but different paths can construct in different ways as appropriate, including to call different constructors or even safely totally delegate construction to another opaque function.

Also, there's a pretty cool (IMO) example in pure2-types-order-independence-and-nesting-cpp2 showing how even with statically guaranteed init-before-use you can can still safely construct a cyclic data structure.

[hsutter]

So this would be valid?

myPtr : *MyType;
myObj := MyType(myPtr,...);

No, that would be trying to pass myPtr as an actual constructor parameter.

And this would be valid as well?

myObj := MyType(...);

Yes, that's fine. It lowers to Cpp1 auto myObj { MyType(...) }; so has identical meaning.

the first out parameter is actually treated like a return parameter instead

The first parameter is the this parameter that's implicit (invisible) in Cpp1 and explicit in Cpp2.

[msadeqhe]

(I get it, and I thought about this too once, but let me push back on it.)

My answer is "but id(args) and arg.id(moreargs) are context-free" -- in fact, banning them only when id is a type would make it not context-free. Why? Because a rule that asks "is id a type?" requires name lookup -- which means it cannot (*) be a parsing rule, but it would have to be a semantic rule. In fact, that's the main reason Type(args) and arg.id(moreargs) are supported in Cpp2... they Just Work from the context-free parse. (Note that cppfront has no semantic rules based on name lookup to see if something is a type, because it can't do that for Cpp1 types since I deliberately don't parse and compile Cpp1 code in cppfront, that's left to the Cpp1 compiler.)

(*) well, had better not! 😁 see this design note and search for "name lookup"

There are other reasons I actually like Type(args) and arg.Type(moreargs), including anytime we have a syntax that lets functions be called using a common syntax we help generic code -- as long as the meaning isn't divergent of course, but it isn't here: This simply allows a constructor to be called like any function. For example std::cout << "xyzzy".std::string(3); prints xyz. Here's a 1-minute clip from my 2021 CppCon talk about common syntax enabling generic code, which was about the importance of a consistent spelling of is and as for queries and casts, and why consistent spelling has always been a major reason to want UFCS (which Cpp2 has).

And if we specifically want a constructor call, we can express that too with the : syntax.

Thanks. Now I understand, and I learned about its use cases. arg.Type(moreargs) is an appropriate syntax for object conversion or object manipulation (like "xyzzy".std::string(3) in your example) where there is a meaning to separate first parameter from the rest of parameters in addition to generic programming:

x: = 10.CustomType();
y: = 10.CustomType(true);
z: = 10.CustomType(true, 2);

So I think I should close this discussion as resolved.