Figure out how/whether we should use P2830 "Standardized Constexpr Type Ordering" in sender/receiver

[lewissbaker]

The paper P2830 states that one of the motivations for adding type-ordering was to help libraries like sender/receiver proposed in P2300.

It looks like this facility is on track to make it in to C++26, so we should figure out exactly where we want to apply this facility in the specification of sender/receiver and write a paper to do so before we ship sender/receiver in a published standard.

e.g. maybe we require that completion_signatures is instantiated with types listed in ascending order as given by std::type_order_v.

Are there any other places we can/want to make use of this facility?
CC: @ericniebler @atomgalaxy

[atomgalaxy]

Anywhere we erase type signatures too. I use it for any_sender_of to sort the vtable, for instance. Every variant type is normalized too.

[lewissbaker]

I think one of the possible caveats to variant type ordering is that often you want to have the first type be monostate so that the default-constructed variant has an empty value. We could still require that the subsequent types listed are sorted according to std::type_order_v, however.

[atomgalaxy]

That's just a different normalizer though. nullable_variant_for instead of variant_for

…

On Sun, Feb 16, 2025, 19:28 Lewis Baker ***@***.***> wrote: I think one of the possible caveats to variant type ordering is that often you want to have the first type be monostate so that the default-constructed variant has an empty value. We could still require that the subsequent types listed are sorted according to std::type_order_v, however. — Reply to this email directly, view it on GitHub <#330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5R5LMGYDPESZYESLXLA32QBR5NAVCNFSM6AAAAABXGL3Z76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRRGM3DMMBUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***> [image: lewissbaker]*lewissbaker* left a comment (cplusplus/sender-receiver#330) <#330 (comment)> I think one of the possible caveats to variant type ordering is that often you want to have the first type be monostate so that the default-constructed variant has an empty value. We could still require that the subsequent types listed are sorted according to std::type_order_v, however. — Reply to this email directly, view it on GitHub <#330 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA5R5LMGYDPESZYESLXLA32QBR5NAVCNFSM6AAAAABXGL3Z76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNRRGM3DMMBUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>