On Sat, Sep 23, 2023 at 2:36 PM Chris Gary via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>>
>> So... what? Ditch any type system, because everything computable can be
>> expressed by integers and arithmetic?
>
>
> Start with general definitions and let implementations specialize. They're just names.

Yes: so why are you making a big deal over a name being in the `std` namespace?

>> Well, you and the C++ committee are going to have to agree to disagree
>> on that point, because that is *not* the direction the language is
>> going in. If the entire basis for your "compelling" justification for
>> your desired change is "we should back-track a bunch of features
>> because I don't think the language should ever depend on the library",
>> then that's not going to convince many people on the committee.
>
>
> My intention here is not to start a flame war. There are serious issues with just tossing new features into namespace std that are making the language more difficult to use where simpler syntax-only solutions would have made things easier.

OK: What are those "serious issues"?

Thus far, you've basically outlined that you don't like them and given
some ideas about why you don't like them. But not liking something
does not mean that it is more difficult to use.

What is your justification for saying that `std::strong_ordering` is
"more difficult to use" than `int`? What is your justification for
saying that "syntax-only solutions" would be "easier" for users to use
(and harder for them to misuse, which is part of ease-of-use)?

> This is not C# or Java. Already with typeid() we ended up "paying" for something unreliable with something that could only be afforded a nebulous role as "a unique ID, but not really".

The reliability or lack thereof of `typeid` has absolutely nothing to
do with `typeid` returning a class type. Even if it were a
compiler-generated type, it would be equally as "reliable", as any
reliability issues are a matter of what the type *does* (or doesn't
do), not how the type got a name.

> reflexpr() allows introspection, but nothing should care about private members or implementation details, this defeats the purpose of access specifiers. Most of the time I need a reflection mechanism, its to do something like apply a "reverse_bytes" on a member-wise basis.

That's nice for yourself, but reflection has to work for people who
have different needs from yourself. Furthermore, whether reflection
allows introspection of private members has absolutely nothing to do
with the mechanisms you use to engage with it. Even introspection of
public members is going to rely on getting and manipulating some
objects that represent the stuff in those members. And that's going to
require a typename, since you should be able to make functions that
operate on reflected components.

And no, a string isn't going to be good enough.

> Cases in point: Lambda functions, variadic templates, and perfect forwarding did not require the addition of new library features, but rather re-working parts of the library to utilize them. They are arguably the most robust and widely used additions to the language since their introduction.

Perfect forwarding is partially implemented with `std::forward`. While
you *could* write your own version of `std::forward`, people rarely
do.