On 3 April 2023 21:35:02 BST, Noah Goldstein via Std-Proposals <std-proposals_at_[hidden]> wrote:
>Hi All,
>
>Idea:
>The idea is to reserve a prefix that will never be used for any member
>in standard structs/classes.
>
>For example if the prefix 'nostd_' is chosen, then the standard is
>agreeing to never make a member that matches 'nostd_*'.
>
>Rationale:
>The rationale is it is sometimes desirable to use custom fields in
>template parameters to support querying for custom features.
>
>For example martinus' quite popular unordered_map implementation [1]
>gives users the ability to tune a performance attribute by adding an
>'is_avalanche' flag to the hash struct [2].
>```
>class hash_unknown_quality {
>....
>}; // The implementation will do extra work to improve the output hash.
>
>class hash_high_quality {
>using is_avalanching = void;
>....
>}; // The implementation will assume the output hash is already good.
>```
>
>Current Issue:
>Under the SD-8 guidelines[3] there is no field in standard structs
>that can be safely assumed to never be used. This can undo any tuning
>value gained by custom fields and makes it impossible to safely use
>custom fields to control correctness related characteristics.
>
>For example 'std::hash' may create a field 'is_avalanching' and
>attach a completely different meaning to it, ultimately undoing the
>value of check in martinus' unordered_map.
>
>Benefit of this Proposal:
>Under this proposal, all custom fields could be prefixed with the
>chosen prefix. This would make these custom fields more reliably
>usable for tuning purposes and safely usable for correctness purposes.
>As well, it may prevent future blockers when trying to upgrade
>standard versions as all custom field checks using the prefix can be
>safely upgraded.
>
>For example if 'is_avalanching' was replaced with
>'nostd_is_avalanching' there would never be the issue of `std::hash`
>creating the field 'nostd_is_avalanching'.
>
>
>
>[1]: https://github.com/martinus/unordered_dense
>[2]: https://github.com/martinus/unordered_dense#3-extensions
>[3]: https://isocpp.org/std/standing-documents/sd-8-standard-library-compatibility

Customisation points through class members this way is generally problematic for the exact reason you describe.

However carving out names that are reserved for user code doesn't solve the problem. Consider an other 3rd party library also using "is_avalanching" with a different meaning. Which library gets to own the name?

There are alternative designs how a library can provide customisation points that doesn't suffer from this problem, like traits or tag_invoke. Or at least there the name collision has to happen on fully qualified names for this to become a problem.

Cheers,
Lénárd