Reflection looks to be possible with just the concept of "unpacking" a
thing and getting a simple string name for any symbol. Possibly fully
backwards compatible with initializer_list (making it an ordinary container
type, since things like it already appear everywhere), eliminating the need
for a special name.

*move and forward can be defined without compiler hooks. This is where the
language does not make architectural assumptions.*
*typeid() cannot.*
*reflexpr() could not.*

coroutines are a different issue I'm still contending with, since they have
always resulted in more architectural problems than they solve...
*This, and things like it, are where the language makes
architectural assumptions.*
How many stacks are we allocating? Why not instead offer first-class fibers
(some kind of enhanced longjmp) and let library authors figure out how they
want to handle the obvious? Polymorphic allocators seem to be a mere
bandage here as well as with stand-alone future<> etc...

Another big hurdle I keep running into is the need for a reinterpret_cast
in a constexpr context. To make that approachable, compile-time debugging
would need to be available, which could begin with user-defined diagnostics
bearing contextual awareness static_assert cannot provide consistently.
OTOH, constexpr reinterpret_cast means constexpr any, which means things
like mbstate_t can be replaced with an any, constexpr string "just works"
and users can roll their own.

The thing is, it's done. The feature has existed for 3 years now.
> You're arguing for why it needs to be changed. None of what you've
> argued for is enough reason to change things as they are. Maybe your
> arguments might have been convincing before it was standardized, but
> now that this has been done, you need a *compelling* reason to have it
> changed.


Compelling: Give the operator a solid definition in general terms, and let
applications specialize. The semantics carried by the present return type
are an architectural assumption because they introduce the need, implicit
or otherwise, to deal with a specific role played where it was demonstrably
not needed beforehand. Ordering semantics are a concern for containers, not
the types they hold, and can be provably unified as specific treatments of
a total order.

At the very least, let new code just return an int. In the case a signed
difference is defined, authors don't have to assume switching over and
returning symbols in std would optimize as expected.

In general: Architecture is disrupted when an unwanted or incompatible role
is introduced or required by a dependency. All C++ applications are now
dependent on the standard library (though I believe this can be reversed
without disrupting existing code). Despite the name, not all standard
libraries are created equally, and probably never will be. It must be
possible to effectively use the language without the library.

Another big issue: Naming things in general. Not everything needs a name,
but all "things" can still be identified by a pattern or some well-defined
isomorphism with another entity.

On Sat, Sep 23, 2023 at 10:51 AM Bjorn Reese via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On 9/23/23 18:01, Chris Gary via Std-Proposals wrote:
>
> > I shouldn't have to #include something to use a language feature.
>
> There are multiple language features that rely on headers: move
> semantic, perfect forwarding, coroutines, non-throwing new, launder,
> and more:
>
> https://en.cppreference.com/w/cpp/freestanding
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>