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

Flags enums: prevent All and None keywords #1251

Closed
decioferreira opened this issue Aug 21, 2015 · 6 comments
Closed

Flags enums: prevent All and None keywords #1251

decioferreira opened this issue Aug 21, 2015 · 6 comments

Comments

@decioferreira
Copy link
Contributor

Should the compiler prevent the definition of All and None keywords on flag enums?

@[Flags]
enum IOMode
  None # 1
  All  # 2
end

puts IOMode::None.value #=> 1
puts IOMode::All.value  #=> 2
@asterite
Copy link
Member

Probably. I don't know if there's a use case where you'd want to overwrite those, and in any case it would yield unexpected results. Thanks for noticing this!

@ervumlens
Copy link

All and None values would be pretty nice to have in a flag enum, defined to the appropriate values. And as long as I'm dreaming, it would be good to have the option to specify the names as well. 😄

Borrowing decioferreira's example:

@[Flags(all: :All, none: :Empty)]
enum IOMode
  In # 1
  Out  # 2
end

puts IOMode::Empty.value #=> 0 because the "none" name was set to :Empty
puts IOMode::All.value  #=> 3 because the "all" name was set to :All
puts IOMode::None.value # error: no such constant

For a default setting, though, it makes sense to provide at least a warning if things like All and None are named in the enum itself.

@oprypin
Copy link
Member

oprypin commented May 14, 2017

I think that having All in all enums without opt-out is bad, because it's an API contract. Someone may want to modify their library and add a flag that makes no sense to have under normal circumstances but people are already using All. And being unable to override it (to keep previous behavior) makes it worse.

@RX14
Copy link
Contributor

RX14 commented May 14, 2017

All Doesn't seem to be used much in the stdlib, I'd be in favour of removing it for the problems it causes when adding new values.

@jhass
Copy link
Member

jhass commented May 14, 2017

I see the argument OTOH it seems like a handy tool too. Maybe we can come up with some more explicit way of defining it, like All = {@all}, which could even allow All = {@all & ~Foo}?

@bcardiff
Copy link
Member

I agree that it would be nice for an opt-out for All/None. And if opted out let the user define/use them (just by plain values as other constants).

All/None have special meaning in Enum#to_s, Enum#each, etc. I wouldn't allow All/None to lose their special semantic.

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

No branches or pull requests

7 participants