I've accidentally spent a good deal of time bothering just one person with
several wrongly-directed responses to this thread.
There are several ideas I'm trying to present, they are all related, though
I'm trying to portion out discussion as to keep things organized.

On Sat, Sep 23, 2023 at 12:47 PM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>