You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Proposal for enhancement of phlex::experimental::identifier #878
The class phlex::experimental::identifier (from now on, just identifier) is in some contexts where it is critical that the string never be empty, and in a few where it is allowable for the string to be empty.
For example, in phlex::detail::product_specification, the member suffix_ is an identifier that is allowed to be empty.
In phlex::experimental::algorithm_name (which is the unique identifier for a node in the graph), the member plugin_ is arguably allowed to be empty, while the member algorithm_ is not allowed to be empty.
In phlex::experimental::layer_path, the member layer_path_ is a std::vector<identifier> none of which should be empty.
The non-emptiness is not always currently enforced at runtime.
There has also been an intent to enforce other restrictions on identifiers, e.g. issue #343 to ensure that identifiers when turned into a std::string are valid C++ variable names.
I propose a change that would make the non-empty nature of identifier be a class invariant for the type, accompanied by the introduction of a new type that can have the state that represents either an identifier or an empty string; this type could have type aliases of suffix_t and plugin_name_t.
This would allow use of identifier as a type in code that would then never need to check if the "string" is empty, for example if emitting the stringified version as a label in a JSON/YAML/FHiCL document, etc., while allowing suffixes and plugin names to be empty when desired.
@marcpaterno, I agree with the thrust of this proposal. I believe it makes sense for suffix_t to be either an identifier or an empty string. I believe, though, that it may make sense for plugin_ to be of type std::optional<identifier> instead of a type that can support an empty string.
What if identifiers constructed from a string / string literal had to be non-empty, but we also have identifier::null which is empty. identifier::null can then be used as a default, but a configuration wouldn't be able to explicitly specify that an identifier field is null?
I hope that's comprehensible.
EDIT: Alternatively, identifiers always have to be non-empty, and we just pick a default suffix that isn't the empty string.
Activity
knoepfel commentedon Sep 10, 2026
@marcpaterno, I agree with the thrust of this proposal. I believe it makes sense for
suffix_tto be either anidentifieror an empty string. I believe, though, that it may make sense forplugin_to be of typestd::optional<identifier>instead of a type that can support an empty string.beojan commentedon Oct 15, 2026
What if
identifiers constructed from a string / string literal had to be non-empty, but we also haveidentifier::nullwhich is empty.identifier::nullcan then be used as a default, but a configuration wouldn't be able to explicitly specify that an identifier field is null?I hope that's comprehensible.
EDIT: Alternatively, identifiers always have to be non-empty, and we just pick a default suffix that isn't the empty string.