Fix private-use units to avoid validity constraints
Description
This is to fix a regression introduced by
I just realized that private-use units (pu_single_unit) in the draft 46.1 references ‘single_unit’, which has have validity constraints in v46.1. That negates the whole purpose. Something like xxx-meter is valid, but xxx-smoot is not (it doesn’t match any existing unit). Moreover, they cannot have multiple parts, so the example given of xxx-square-knuts is illegal on two counts (square-xxx-knuts would be ok).
To fix this, we should change the pu_single_unit to the following:
Fix cherry-picked to maint/maint-46 branch 2024-12-08
Mark Davis December 8, 2024 at 5:06 AM
Yes, thanks!
Peter Edberg December 8, 2024 at 3:28 AM
And I am taking the liberty of moving this to Done with Steven (who approved the PR) as reviewer, to clean up ticket status before the cherry-pick to main branch. Hope that is OK.
This is to fix a regression introduced by
I just realized that private-use units (pu_single_unit) in the draft 46.1 references ‘single_unit’, which has have validity constraints in v46.1. That negates the whole purpose. Something like
xxx-meter
is valid, butxxx-smoot
is not (it doesn’t match any existing unit). Moreover, they cannot have multiple parts, so the example given ofxxx-square-knuts
is illegal on two counts (square-xxx-knuts
would be ok).To fix this, we should change the pu_single_unit to the following:
pu_single_unit
:= ("xxx-" | "x-") [a-z0-9]{3,8}
Examples:
square-xxx-knuts
(a Harry Potter unit)Notes:
"x-" is only for backwards compatibility; it is deprecated and should not be generated
See Private-Use Units
Background
Here is the current status in the draft v46.1, where single_unit ends up referencing base_component (where the validity constraint is — I bolded that)