In RFC0430 (Naming conventions), i think it makes sense to allow SCREAMING_SNAKE_CASE for unit-like types and enum-variants, since both of them can be used in a constant-like way.
Bikeshed: I would argue the polar opposite, that we should ditch all usage of screaming snake case.
"Can be used in a constant-like way" does not mean that they are constants. Notably, they are still types, and not values. So this actually doesn't make sense.
@H2CO3, actually unit types live in both the type and value namespace, so they are both : ). That's why you can do let x = UnitType;
Those are necessarily different contexts though. UnitType as an expression is just one of the syntaxes for value constructors. Which is conceptually distinct from both the type UnitType and a constant of type UnitType (and value UnitType). This difference would stand even if for e.g. reasons of simplification, they were implemented interchangeably in the compiler. (I don't know whether they are, but my point is that it shouldn't matter.)
I actually agree that semantically this makes sense because we'd gain value from distinguishing ZSTs. We'd only realize those gains if we forced such usage, but screaming snake case really is extremely ugly, and this seems way too late to change.
For a mirror issue "allow PascalCase" in enum-variant-like positions", see https://github.com/bitflags/bitflags/issues/198
@burdges Actually the original intention is to "additionally allow", not "change".
I'm dubious that adding variety improves semantics in this case, well in come cases it does yes but here not so sure.
Most helpful comment
Bikeshed: I would argue the polar opposite, that we should ditch all usage of screaming snake case.