The suggestion you are referencing for attributes that didn't support
string literals was quickly dismissed in favor of an alternative
value-based decorator, so I think you can put that concern to rest. As for
enum field string conversions, that's already possible using the existing
proposal (as are field names and other such things). The recent discussion
you are referencing was strictly about user-defined attributes, which were
not yet mentioned in the paper.

As far as my understanding regarding the conclusion of the discussion,
there was good interest, although it seems like user-defined
attributes/annotations/decorations (whatever we call them) may not be in
the initial version of the proposal, although I will defer to the paper
authors to make a more concrete statement about this.

On Sat, Oct 21, 2023 at 5:13 PM Hadriel Kaplan via SG7 <sg7_at_[hidden]>
wrote:

> Howdy,
>
> One of the emails in the thread mentioned that one proposed idea for this
> would not support string-literals. (I think?)
>
> If you're interested in comments from the peanut gallery: for at least one
> use-case, we need user-definable string-literals - either in attributes, or
> in _something_ that we can get via reflection.
>
> Because the use-case is for certain cases of enum-to/from-string, to
> assign a user-definable string-literal for each enumerator of each
> enumeration; alongside the enumerator in the enum's enumerator-list
> declaration.
>
> And we need that because the enumerator names are not always the same as
> what we need them to be as strings, and are not automatically convertible
> via a simple algorithm/function either.
>
> But as someone already said: this would be for round-2. Just getting _any_
> reflection to enable enum-to/from-string would be great!
>
>
> ---
>
> If you're looking for some anecdotal data: in the codebase I work on, of
> the ~1500 enums reflected via macros today, 500 or so have user-defined
> strings for enumerators.
>
> I looked through some of those types to see what they were being used for,
> that required their strings to be manually set.
>
> Many of them we could do programmatically instead, if the whole
> enumeration had a user-definable type or constexpr value that we could
> reflect, because they're things like lowercasing/uppercasing, or changing
> underscore '_' to dash '-', or similar such transformations.
>
>
> But many of them could not be auto-transformed, and need to have
> user-definable arbitrary strings.
>
> The ones I saw for such cases were due to (in no particular order):
>
> * Descriptive debugging output when the enumerator value is logged or
> used in an exception's string. (ie, it's more than one word)
>
> * Shorthand/condensed debugging output when the enumerator value is
> logged. (ie, it's only a couple characters)
>
> * Output for user-visible display purposes, such as for
> interactive-terminal display output.
>
> * Multi-word command strings, such as when each enumerator represents an
> option or command for a spawned shell subprocess.
>
> * Serialization to/from JSON/XML, where the string value has changed in
> the schema and we need to support two potential input strings for the same
> enumerator.
>
> * Serialization to/from JSON/XML, where only some enumerator values of
> an enum need different styles or unusual characters (e.g., an '@'
> character).
>
> * Parameterized unit-test values with enumerators representing
> ip-addresses, or host or domain names, or filenames, or various other
> strings.
>
> * Lexer/parser tokens, where the enumerator value represents a defined
> string token in a grammar.
>
> Most of the above are for to-string only, some for from-string only, some
> both.
>
> For the JSON/XML ones, the string values are not under our control -
> they're based on standards or third-party interfaces/schemas.
>
> -hadriel
>
>
>
> Juniper Public
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>