> It seems presenting ideas here without first providing a toy
implementation never gets any traction. "If you can't hack it into
Clang, then nobody cares."

I certainly do not think that "nobody cares" here, just look at the
tremendous amount of replies got generated, I didn't count the exact
number, but I'm sure we're over 20;
and at least from 5 different people (which includes active committee
members). You actually did get a lot of attention, with a fair amount of
text in responses to your OP,
with detailed explanations as to why people reading this thread actually
judge that what you propose has not enough value to get moving forward.

Even though you could be right in identifying an unsolved problem, and
if so, that your proposed solution is a good one, people are saying "I'm
not convinced".
(Think of special relativity, nobody took it seriously; it only was
accepted years later, when a rigorous experiment disproved the "Ether
model").
If you fail to convince others, or nobody seem to see the problem you
indicate as something worth fixing, then you must try to prove your point.
Rephrasing things, or replying by adding more sentences like "things
should be like this" (which already sound opinionated),
or personal anecdotes of the kind "something broke when I did this, but
shouldn't had" (which is hypothetical), then it's not going to be
perceived seriously,
and is no more convincing than repeating the same thing over and over.

If you want things to go forward, you need to break this
"argument-counterargument" cycle, you need to rigorous proof that
1) there really is an outstanding problem that needs to be fixed;
2) and that your solution fixes this problem without bringing in
contradictions or breaking other people's (conforming) code;

What I mean by a "proof" is, a tangible, reproductible experiment with
consistent observables: describe the steps of the experiment so that
anyone can
run it, and then come up with consistent observations leading to the
same conclusions.

The sentence "If you can't hack it into Clang, then nobody cares."
sounds more like a catch phrase and can be taken to mean "prove your
point using a rigorous method".
If you someone wants to propose some change in the language's syntax,
starting a topic branch from clang is usually a convenient experimental
setup to support their proposal.
Other methods are not excluded.

> ... and even in my personal projects I really do not care about that
kind of thing

The terms "my personal projects" and "I do not care about that kind of
thing" are antithetical to collaborative work --
how about the reciprocal "We don't interact with your personal projects,
so we don't care about the problems you encounter or your personal
specific needs".
A problem is worth solving if it reaches more people than just you;
A solution has value if it improves the language for everyone, in way
consistent with the philosophy of the language.

BTW, If you don't like that language mechanics to interact with std
library headers, C language has come with the "nice solution" of introducing
new builtin types with new builtin operator semantics for complex
numbers and booleans. To do so, in a portable way (without breaking
backward compatibility),
type names needed to be in the _Reserved_identifier space, and more
special cases in the formal description of builtin operators (as C
cannot support builtin type's syntax for user defined types).
Does anyone have objection if I'd say `std::new_type` is better than
`_New_type` or that implementing an `operator+` directly in C++ is
better than adding a new special case to the builtin operator `+`
to support the semantic of some `_New_type`? If I recall, supporting
user defined types with syntax similar to builtin types is foundational
in C++.

Julien V.

On 2023-09-24 10:38 p.m., Chris Gary via Std-Proposals wrote:
> have to come back to these things later.