@Dirk, by "what would be allowed." I meant a positive regex. Omissions are too easy with a negative character set. For example, quote characters.
> WHY?
My main point is that a restricted character makes it easier for future syntax to be designed around PVD field names. Be it CALC expressions in records or in OPI systems like cs-studio.
cf. "pva://SomePVName/subfield/subelement" in cs-studio. Which practically excludes '/' in both record and field names.
As for the specific case of PVXS. Having a different separator for structure and union allows for fewer std::map lookups, giving faster parsing (PVD does a lot of these lookups...).
@Dirk, by "what would be allowed." I meant a positive regex. Omissions are too easy with a negative character set. For example, quote characters.
> WHY?
My main point is that a restricted character makes it easier for future syntax to be designed around PVD field names. Be it CALC expressions in records or in OPI systems like cs-studio.
cf. "pva:// SomePVName/ subfield/ subelement" in cs-studio. Which practically excludes '/' in both record and field names.
https:/ /control- system- studio. readthedocs. io/en/latest/ core/pv/ doc/index. html#pv- access
As for the specific case of PVXS. Having a different separator for structure and union allows for fewer std::map lookups, giving faster parsing (PVD does a lot of these lookups...).