Skip to content

Proposal for enhancement of phlex::experimental::identifier #878

Open

Description

@marcpaterno

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.

Activity

  1. knoepfel commented on Sep 10, 2026

    @knoepfel
    Member

    @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.

  2. added this to the Prototype 0.5 milestone on Sep 30, 2026
  3. added theissue type on Oct 1, 2026
  4. beojan commented on Oct 15, 2026

    @beojan
    Contributor

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions