Re: New switch/case idea
- Posted by jeremy (admin) Apr 06, 2009
- 1736 views
I wonder, not changing it, because it would indeed be confusing, but giving a warning if a break is given inside of an if statement w/no label? It almost always means an error. In fact, it would always mean an error? Maybe it should be an error actually? When would it ever be a good thing?
Jeremy
break is still useful for getting out of nested if statements.
Indeed. I like break for nested if's.
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.
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. 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.
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... 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
