Skip to content
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

Open
crlf0710 opened this issue Jan 29, 2020 · 7 comments
Open

Allow SCREAMING_SNAKE_CASE for unit-like types and enum-variants. #2860

crlf0710 opened this issue Jan 29, 2020 · 7 comments

Comments

@crlf0710
Copy link
Member

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.

@Lokathor
Copy link
Contributor

Bikeshed: I would argue the polar opposite, that we should ditch all usage of screaming snake case.

@H2CO3
Copy link

H2CO3 commented Mar 27, 2020

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

@RustyYato
Copy link

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

@H2CO3
Copy link

H2CO3 commented Mar 27, 2020

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

@burdges
Copy link

burdges commented Mar 27, 2020

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.

@crlf0710
Copy link
Member Author

crlf0710 commented Mar 28, 2020

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

@burdges
Copy link

burdges commented Mar 28, 2020

I'm dubious that adding variety improves semantics in this case, well in come cases it does yes but here not so sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants