http://d.puremagic.com/issues/show_bug.cgi?id=199
--- Comment #27 from Nick Treleaven <[email protected]> 2013-05-30 08:41:41 PDT --- (In reply to comment #16) > (In reply to comment #15) > > Walter Bright, comment #6: > > > I don't want to change this because it could break existing code > > > > We could deprecate having a BlockStatement after a label, with a message > > suggesting to move the label within the block. That way no code gets broken. > > Wait. What? Deprecate having a block statement after a label? Why would we do > that? That's completely arbitrary. Plus, that would *definitely* break more > code than what we'd break with a straight up fix. In order not to break code. I'm skeptical that a solution which causes any existing, debugged working code to silently break will be accepted, and I think that opinion makes sense. If we are to avoid all possible code breakage, it's simple to just deprecate non-empty block statements after a label, since there are two workarounds (see comment 15) which do not require changing existing scope semantics. The deprecation message can advise the user of the workarounds. I omitted to mention that an empty block statement after a label should still be allowed, as that is not bug-prone. Maybe I wasn't clear - by deprecating I mean permanent deprecation without removal, essentially a warning that you can turn off if you really want to by silencing deprecation messages. > This behavior was never according to spec anyways. I say we just fix it. It's a trade off between either breaking working code or annoying users with deprecation messages that need small fixes to their code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
