[Issue 199] Label causes scope to collapse into parent

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=199



--- Comment #28 from monarchdodra at gmail.com 2013-05-30 09:21:14 PDT ---
(In reply to comment #27)
> (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.

Just seems that because something is broken, your solution is to simply
deprecate the entire feature. There is no reason to make labeling a block
illegal or deprecated.

The correct solution would be to find a path that doesn't break code, but still
marks invalid code as such, and give users a pre-emptive chance to fix the
code, before it is definitely banned.

The (imo correct) path is that the NoScopeStatment should still provide no
scope, but emit a deprecated message if anything declared in the scope is used.
EG:

void main()
{
    label:
    {
        int i;
    }
    writeln(i); //(1)
}

(1) should emit a deprecation message.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------