Yet another terrible compile time argument proposal

[bomat]

On Tuesday, 16 January 2024 at 00:29:20 UTC, zjh wrote:
> It's just a few `constructors`, it's easy to distinguish.

It's a mess.

Look, I don't want to derail this discussion, I cannot even judge 
the usefulness of the proposal, I just want to whole-heartedly 
agree with Paul Backus about the point that you can overdo it 
with adding bells and whistles, especially when you never 
deprecate (let alone remove) old stuff because of backwards 
compatibility.
And if C++ is not a great example for that, I don't know what is.
It's not "just a few constructors". At this point it's absolutely 
everything. Everything can be done in 7 different ways, but of 
course with tiny nuances that nobody can understand anymore. The 
logic by which a C++ compiler will generate default ctors and 
copy-operators based on which ones you have defined manually is 
literally quantum mechanics: look at the system too hard and you 
will change its behavior. Asylums are filled with people who 
tried to understand what actually happens when a C++ function 
returns a value.
Whenever I meet people who call themselves "C++ experts" (e.g. in 
job interviews - great fun), I ask them for the difference 
between an lvalue, an rvalue, a glvalue, a prvalue, and an 
xvalue, just to show them how wrong they are. Usually they think 
I made those up, and I wish I had.
The bottom line is: That level of complexity is "the last thing D 
needs":
https://www.youtube.com/watch?v=KAWA1DuvCnQ