Date: Sun, 24 Sep 2023 14:57:38 -0600

> What does that mean for NaN <=> 1.0 ?

>

NaN <op> NaN is false for <op> : (arg,arg) -> bool

NaN <=> NaN -> -2

..which could be reserved for a ternary, meaning "undefined". Or, any value

*not*, -1, 0, 1.

I proposed int as to avoid exactly what happened in this thread anyway.

So, in better disclosure, I've had success in the past with a "rich" enum

ternary type made for an override of a "Compare" function.

Here's a snippet:

`

enum class Relation : int

{

Undefined = -2,

Less = -1,

Equal = 0,

Greater = 1

};

inline constexpr Relation ClampToValid( Relation r ) noexcept

{

const auto u = (int)r + 1;

const auto v = 2 - u;

const auto w = u | ((u|v) >> (bitCount<int>-1));

return (Relation)( w - 1 );

}

// Relational operators that take "Relation" etc...

`

Now, if <=> could just return `int` or anything that can round-trip to an

`int` implicitly, *and* enum classes could expose implicit conversions,

this could all be safely encapsulated without creating incorrect code that

tries to compare a `Relation` value and not getting the magic `undefined`

result - everything would get mapped into to the set {-2,-1,0,1} before

comparison. The "sign of difference" rule still applies everywhere, and

comparisons are allowed to return any other random value to mean

"undefined". In cases where the meaning of the return value means more than

just "undefined", and the code still assumes the semantics of "Relation",

it wasn't written to deal with the failure anyway (generally, just capture

the original int and propagate an error/throw an exception).

On Sat, Sep 23, 2023 at 1:43 PM Jonathan Wakely <cxx_at_[hidden]> wrote:

>

>

> On Sat, 23 Sept 2023, 16:45 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.

>>

>

>

> What does that mean for NaN <=> 1.0 ?

>

>

>

>> 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...

>>

>

> That seems like a rather silly self-imposed limitation.

>

>

>

>

NaN <op> NaN is false for <op> : (arg,arg) -> bool

NaN <=> NaN -> -2

..which could be reserved for a ternary, meaning "undefined". Or, any value

*not*, -1, 0, 1.

I proposed int as to avoid exactly what happened in this thread anyway.

So, in better disclosure, I've had success in the past with a "rich" enum

ternary type made for an override of a "Compare" function.

Here's a snippet:

`

enum class Relation : int

{

Undefined = -2,

Less = -1,

Equal = 0,

Greater = 1

};

inline constexpr Relation ClampToValid( Relation r ) noexcept

{

const auto u = (int)r + 1;

const auto v = 2 - u;

const auto w = u | ((u|v) >> (bitCount<int>-1));

return (Relation)( w - 1 );

}

// Relational operators that take "Relation" etc...

`

Now, if <=> could just return `int` or anything that can round-trip to an

`int` implicitly, *and* enum classes could expose implicit conversions,

this could all be safely encapsulated without creating incorrect code that

tries to compare a `Relation` value and not getting the magic `undefined`

result - everything would get mapped into to the set {-2,-1,0,1} before

comparison. The "sign of difference" rule still applies everywhere, and

comparisons are allowed to return any other random value to mean

"undefined". In cases where the meaning of the return value means more than

just "undefined", and the code still assumes the semantics of "Relation",

it wasn't written to deal with the failure anyway (generally, just capture

the original int and propagate an error/throw an exception).

On Sat, Sep 23, 2023 at 1:43 PM Jonathan Wakely <cxx_at_[hidden]> wrote:

>

>

> On Sat, 23 Sept 2023, 16:45 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.

>>

>

>

> What does that mean for NaN <=> 1.0 ?

>

>

>

>> 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...

>>

>

> That seems like a rather silly self-imposed limitation.

>

>

>

Received on 2023-09-24 20:57:51