Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
`switch` statement: prevent nonsensical / repeated options #8598
Summary of the new feature/enhancement
While the precedence rules that apply when incompatible / repeated options are passed to the
Notably, the following combinations are currently permitted, with the last option winning:
Proposed technical implementation details (optional)
Report a parse-time error when such pointless combinations are found.
Technically, that would be a breaking change, but, I hope, of type Bucket 3: Unlikely Grey Area.
This should be relatively straightforward, I should think. Probably have to pick it up in the tokenizer, or potentially the parser if that turns out to be a simpler point to detect it at (as it well might, it having been already neatly chopped into tokens by that point).
Are there any other keywords that take parameters like this? I can't think of any off the top of my head, but if there are we probably ought to check we don't have a similar error there.
I'm glad to hear it, @vexx32.
From what I can glean from
I have never even heard that mentioned in passing. Ever. Didn't even know that was a language keyword, and I've read that help doc several times.... wow. Must have just skimmed over it a good many times.
That needs a thorough write up... guess I know what I'm doing for next week's blog, haha! That is really nice to know about, thank you!
referenced this issue
Jan 7, 2019
But they are not actually mutually exclusive. You can specify multiple options and the last one wins (i.e. order matters). So this is definitely a breaking change. What benefit would we accrue from taking this breaking change?
From a historical perspective, IIRC, in V1, there might have been some thought that these would be switch parameters but because they are language elements instead of parameters, that doesn't work. @JamesWTruher @khansen00 - do you guys remember any more details about this?
@vexx32 The code is here:
To add to @vexx32's comment:
That they're not actually mutually exclusive is the very reason for creating this issue: they should be, which brings us to why this change is worth making:
If we prevent nonsensical / pointless use to begin with, we reduce complexity in several respects:
As for what could break: