strong_type add support for three-way comparison

Jun 08 '22 08:06 timblechmann

The failure with Windows C++20 is issue #18, so never mind that. I need to think a bit if having both a full set of comparison functions <,<=,>,>= in addition to <=> is what is desired.

Jun 10 '22 11:06 rollbear

The failure with Windows C++20 is issue #18, so never mind that. I need to think a bit if having both a full set of comparison functions <,<=,>,>= in addition to <=> is what is desired.

in most cases <=> should make the other comparison functions obsolete, though i wonder if there are some edge cases, where users implement the comparison functions differently from <=>? e.g. with different logging/tracing or for a dsl where the operators have a completely different semantics :thinking:

Jun 11 '22 00:06 timblechmann

It looks like for comparisons using the ordering operators, they have precedence over <=>, whereas an explicit call to operator<=>() goes through as expected. I have not read what the standard document says, but this makes sense.

https://godbolt.org/z/vn9Mvs4a8

The question of whether this is the desirable outcome here, is still open, I think.

Jun 15 '22 06:06 rollbear

@rollbear, i was wondering on how to go forward with this?

Mar 07 '23 01:03 timblechmann

I was discussing this with a colleague only yesterday, and it's not obvious how to best do this. I'm currently leaning towards having modifiers representing the different orderings that can be represented by <=>, so for example:

using type = strong::type<int, struct int_, strong::regular, strong::partial_ordering>

which would implement:

std::partial_ordering operator<=>(const type&, const type&)

Maybe add another level of indirection in the implementation, to allow for using the type names from namespace std,

using type = strong::type<int, struct int_, strong::regular, std::partial_ordering>

Do you think this would be a move in the right direction?

Mar 07 '23 05:03 rollbear

i do like the approach of using an explicit strong::partial_ordering, it gives a bit more control over just relying on the type-inferred result of <=>

Mar 18 '23 07:03 timblechmann

I was not aware of this when I created #35 .

May 02 '23 22:05 HazardyKnusperkeks

No worries, @HazardyKnusperkeks. I'm meeting with a bunch of people today, much more skilled than I am, and we'll discuss this. I hope we'll agree on what's the best way to model this, and from there it should move forward quite quickly. I apologize for the long delay with this, but I'm worried about getting stuck with an unfortunate design.

May 03 '23 05:05 rollbear

Please have a look at branch spaceship and let me know if you find issues with it. I had to do some shenanigans with clang/libc++ versions 10 through 14, which flagrantly lies about what it supports. Ping @HazardyKnusperkeks

May 06 '23 05:05 rollbear

Please have a look at branch spaceship and let me know if you find issues with it. I had to do some shenanigans with clang/libc++ versions 10 through 14, which flagrantly lies about what it supports. Ping @HazardyKnusperkeks

Comparing with == and != does not work with strong::strongly_ordered, is that intended? (It is also not contained in the tests.) I can add strong::equality, but the question is, is that what you want? You could add operator== as I did in my try.

May 06 '23 20:05 HazardyKnusperkeks

Any news?

Jun 22 '23 08:06 HazardyKnusperkeks

So sorry for the delay. I made the "mistake" of asking about the interaction between <=> and ==, and more than a handful of committee member suddenly felt very uncertain about what actually is the desired outcome. Let's say that I'm glad I'm not in the business of teaching this language. I am off to C++OnSea soon. I hope I can resolve this shortly after, unless even more confusion ensues. I will need to work a bit on the README.

Jun 25 '23 22:06 rollbear

So sorry for the delay. I made the "mistake" of asking about the interaction between <=> and ==, and more than a handful of committee member suddenly felt very uncertain about what actually is the desired outcome. Let's say that I'm glad I'm not in the business of teaching this language. I am off to C++OnSea soon. I hope I can resolve this shortly after, unless even more confusion ensues. I will need to work a bit on the README.

Thanks! Could you pick the fmt fix (which incidentally I ran into shortly after the fix was merges) to your spaceship branch? Then I could update my code to that, instead of my branch. I know and accept that it may change what is provided by strongly_ordered etc.

Jun 27 '23 10:06 HazardyKnusperkeks

Thanks! Could you pick the fmt fix (which incidentally I ran into shortly after the fix was merges) to your spaceship branch? Then I could update my code to that, instead of my branch. I know and accept that it may change what is provided by strongly_ordered etc.

This is merged to main now, but can you please remind me of what the fmt issue is? It seems to have slipped my mind. Or are you referring to "const formatter<>&"? (commit cf1613ad1960fe09c33809881a789ea2c75d609a) already on main?

Jul 20 '23 19:07 rollbear

Thanks! Could you pick the fmt fix (which incidentally I ran into shortly after the fix was merges) to your spaceship branch? Then I could update my code to that, instead of my branch. I know and accept that it may change what is provided by strongly_ordered etc.

This is merged to main now, but can you please remind me of what the fmt issue is? It seems to have slipped my mind. Or are you referring to "const formatter<>&"? (commit cf1613a) already on main?

Yep, that was what I referred to.

Jul 20 '23 19:07 HazardyKnusperkeks

Closing this. The functionality is added in a different way. Thank you for the suggestion and the work and your patience.

Jul 20 '23 19:07 rollbear