-
Notifications
You must be signed in to change notification settings - Fork 175
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
Switch
attribute for unique and/or full Case
s
#451
Comments
Yeah, I think all of these should be implemented as lints with configurable severity. |
I actually disagree that these should be lints. To my mind, a lint would make sense if the property we were looking for wasn't wholly contained to a particular language construct. In this case, the semantics of |
Two reasons:
|
I see. I agree that 2 is a good reason to have a lint. I'll sit and think a bit about whether I want a lint also or a lint instead. For 1, what do you mean by "lightweight"? Syntactically, at least the way I'm imagining them working (and yes, I know we haven't designed them yet), from a user perspective using a lint would be heavier-weight than passing a constructor argument (not to mention adding rightward lean), but maybe you have a different mental picture. |
In the sense that it doesn't introduce changes to the core language, not in terms of end-user syntax. I agree that syntactically a lint can end up being heavier. |
We discussed this on the meeting. The conclusion was that we want both the Also, without the kwarg, disabling the lint for just a single |
I'm going to close this issue since not much need has been expressed for this feature and as a consequence there are no current plans to add support it. Please feel free to comment on this issue if you would like to see it happen. Please also note that there was no strong consensus on whether the feature should be implemented as a lint or as a syntactic feature. It is not clear whether it would work well as a lint (that should probably be trialed on Amaranth code); as for it being a syntactic feature, it is unclear how it would interact with value-castables, which were introduced after this proposal has been made. |
It would be useful to be able to indicate that a Switch should cover all possible Cases, or at least that the given Cases should not overlap.
The text was updated successfully, but these errors were encountered: