Re: New switch/case idea
- Posted by jimcbrown (admin) Apr 06, 2009
- 1715 views
However, it is hard to see a use of break for a single if-statement.
I can't see any use for it. It's like code after an abort() call, there is no reason, it never will be executed.
Actually, break doesn't have an effect in a while loop right? So someone could code up:
if x then while y do if z then retry end if break end while end if
A more fleshed out example:
if fn != -1 then text = "" for i = 1 to nbytes do -- at most read nbytes bytes integer c = getc(fn) s &= c if s != -1 then continue end if break end while end if
Granted, there are much saner ways of doing that...
Perhaps we could only allow break to break out of an if-statement if a label is used, otherwise it defaults to break out of the switch (and is an error if there is no label and no switch).
Still, I'm a bit leery about doing this.
I don't care for that, would cause too much confusion.
Agreed. It is a bad idea.
I am for throwing a compile error, however in this situation:
if 1 then -- do something break end if
A break w/o label has no place. If a user enters it, it's either because they forgot the label or they do not know what break actually does. In either case, an error should be thrown and then their will either add the label or read as to what break is.
Require all breaks in an if-statement to have a label? I'm still a bit leery about doing that as well.
Well, as I am thinking about this, there is one case, and it may not be a very good case, but... say you are debugging and something is wrong with your new section of code, you can add a break and that would cause from then down not to execute, but I'm not sure if that's a good enough reason to make it valid. At bare minimum we should throw a warning, but I think I am in favor of a error...
At the moment we have the same situation with the return keyword. I used to just stick a return in a function to have it ignore the code below, though that would generate a warning.
With multiline coments though, do we really still need this?
Thinking aloud some more.. We have block comments now, so if you don't want the code to execute, throw a block comment around it.
Jeremy
Or use an ifdef, etc.
