New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow SCREAMING_SNAKE_CASE for unit-like types and enum-variants. #2860
Comments
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 |
Those are necessarily different contexts though. |
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 bitflags/bitflags#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. |
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.The text was updated successfully, but these errors were encountered: