I'm already dealing with initializer_list<> refining another idea (it seems
to work, though). IMO, the philosophy for new language features ought to be
to avoid making more things like typeid().

I shouldn't have to #include something to use a language feature.

Moreover, every compare ever written beforehand returned an 'int'. The
idea that the return type needed to carry more semantic information could
have been realized by allowing different return types in special cases.

The opening claim is easy to observe, all things we understand are actually
different images of integers. The return type really ought to have been as
simple as possible in the first place. The "sign of the difference"
definition could give it a simple, but complete justification, doing away
with "but, int is old-timey" - the answer is, did we really need a
semantically-laden type for a ternary?

On Sat, Sep 23, 2023 at 9:52 AM Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sat, Sep 23, 2023 at 11:45 AM Chris Gary via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > All computable data can be made isomorphic to integers.
> > It is always possible to define a total ordering.
> > Even N-d points have a total ordering in the form of space-filling
> curves.
> > N-d rational points are the same: Reduce the coordinates so they are
> unique, then either use zig-zag or interleave the bits numerator then
> denominator to get a Morton index for some weird N+1 or 2*N dimensional
> space (not the same in the spatial sense, but this at least allows them to
> be used in an ordered container).
> >
> > For all scalar types, spaceship could become int-valued and return the
> sign of the difference in the form of an int.
> >
> > Let the ordering in the case of an 'int'-valued operator <=> be assumed
> the same as std::strong_order where it is not otherwise defined explicitly.
> >
> > In the context of deducing the result type of operator <=>, it could be
> allowed either for backwards compatibility. That, or implicit "cast" of
> "int" to a "std::strong_order" where it is required.
> >
> > Frankly, I've avoided using operator <=> due to header issues and the
> strangeness of a formal operator returning a privileged type in namespace
> std. I wouldn't be surprised if I've missed a detail...
>
> Why?
>
> Why does the standard need to change this? Because you don't like
> having an operator return a "privileged type in namespace std"? Why
> should that matter? It's not like `typeid` hasn't done that since
> C++98. It's not like list initialization as a language feature is not
> fundamentally bound to the `std::initializer_list` type.
>
> What is the advantage of returning an integer instead of a specific
> kind of ordering? Will it improve performance? Will it fix some actual
> problem programmers will have? Or is it just personal preference?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>