should queries be required to have a UUID so that there is a global canonical ordering?

[ericniebler]

[lewissbaker]

What is the purpose for having a global cannonical ordering of queries?

• So that listing environment-queries is always returned in a standard order?
• To reduce number of instantiations of type-erasure vtables?
• Something else?

I think in general, that the proposed facility for sorting types (P2830) would provide an equivalent guarantee without needing to introduce UUIDs.

One place where UUIDs can be useful is where you are implementing a query-interface like thing where you are trying to communicate a type-id across a type-erased/ABI boundary. Normally you would just pass a std::type_index, but that doesn't work in environments that have disabled RTTI (although whether you want to support such environments is another question).

[lewissbaker]

This was discussed in a meeting of some P2300 authors on 2024-10-03 and there was general aversion to introducing UUIDs on queries in the absence of more compelling motivation for it, and a general preference for some ability to sort based on some intrinsic property of the type (like P2830).

In terms of improving compile times for uniquing types, clang is in the process of producing a builtin/intrinsic that does this more efficiently. See https://discourse.llvm.org/t/rfc-adding-builtin-for-deduplicating-type-lists/80986/19 for a discussion on this.

There is also some discussion in that thread around adding an intrinsic for sorting types. However, there will be no guarantee that the order produced by this intrinsic will be consistent with whatever P2830 defines as the ordering (unless that specification solidifies and is implemented as part of the sorting intrinsic).

@ericniebler are you able to elaborate on the particular problem that motivated you to create this issue for assigning UUIDs to queries?