Re: New Switch Idea
- Posted by DerekParnell (admin) Mar 27, 2009
- 1127 views
If I remember correctly, we had optional then's and do's added to Euphoria and it was quickly reverted.
The 'switch' is in a different situation though. In the other cases, anything could possibly occur after the 'do' keyword so it is impossible to recognise where the 'if/while/loop/etc' clause ended and the statement block started. In the 'switch' situation, the only valid thing after the 'do' is the 'case' keyword, and thus the first 'case' occurance signals the end of the 'switch' clause - the 'do' is actually redundant.
Maybe do is not the correct word, but Jim suggested "on" which sounds nice.
Yes 'on' is better than 'do', but is it worth a new keyword that would also be redundant?
He also suggested case <value> then which keeps with Euphoria syntax.
I'm sorry, but I don't understand what you mean. Is this instead of the 'switch <expr>' or are just saying that the colon is optional?
I thought that we had decided to add things like this in 4.1? If we do that now, I believe we are changing switch quite a bit and are going to push back 4.0 further. Adding them later on does not change the syntax for switch, it will only make some things easier.
Sure leave value lists for 4.1. I'm fine with that. It's not too hard to do anyway.
- <statements> is a block of one or more euphoria statements. A zero length statement block is not allowed.
I personally, really liked the idea given by Matt, as copied from C#, of a smart switch that allowed:
switch X do case 1: case 2: case 3: -- do something end switch
Now, with your full proposal of allowing case 1,2,3: I guess the smart switch does make less sense to be excited about because you solve the same problem with allowing a list of items, then the block of code. I am assuming that case 1,2,3 would be written the same as the IL code of case 1: case 2: case 3: ?
At first reading I thought the empty case fallthru was a good idea too, but later I realized it would introduce an exceptional situation that may be more confusing to have than not have. It would mean that sometimes there is automatic fall though and sometimes there is not, with similar looking syntax. By not allowing zero-length statement blocks, it means that all 'case' clauses have the same default behaviour with in a switch statement.
And yes, the value list would generated IL that used the same jump-table logic as currently happens. It is just a syntax-sugar with much reduced typing.
- If 'without fallthru' is in operation, once <statements> block is executed, control passes to the 'end switch' line. Any 'break' statements are ignored.
Why ignore a break? What if there were some condition in place that the user wanted to break from?
Maybe it was poor wording on my part. What I meant was that in effect any explicit break statement at the end of the statement block would be ignored because all statement blocks would behave as if there was a 'break' already there.
We don't want to make the wrong decision with switch, ... I am a bit concerned that if we rush to allow multiple values per case statement that come 4.1 when we sit down and think long and hard about it that we may create a syntax incompatability, or wish we wouldn't have rushed to make it in 4.0.
Of course. But I only recall two value-list suggestions, one with braces and one with out. It was agreed that the braces would not be useful after all and could be omitted and still have a valid list.
