Date: Sat, 21 Oct 2023 23:13:40 +0000
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
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
Received on 2023-10-21 23:13:44