[Issue 827] Trying to break out of a labelled BlockStatement breaks out of a for loop at its beginning

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Jun 23 16:04:32 PDT 2008


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


smjg at iname.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




------- Comment #3 from smjg at iname.com  2008-06-23 18:04 -------
(In reply to comment #2)
> It works as spec'd,

No it doesn't.  The statement from the spec that I already quoted is still
there, word for word.

> and you're right it is the same issue as 199.

Maybe within the compiler, but not insofar as according to the language, the
label is of the BlockStatement not of the ForStatement therein.  What the label
labels and whether the BlockStatement opens a new scope or not are essentially
distinct concepts.

> Won't change behavior for the same reason.

If you're referring to bug 199 comment 6, neither point seems to me to apply
here:

> I don't want to change this because it could break existing code,

Somebody who wants the existing behaviour of my code example can just use

void main() {
    block: for (int i = 0; i < 10; i++) {
        if (i == 5) break block;
    }
    writefln("Within block");
    writefln("Outside block");
}

so what's there to break?

> and there doesn't seem to be a compelling reason to do so.

I certainly think there is: the nasty shock a programmer gets on trying this
code, expecting it to (a) be legal (b) if so, behave in a way that makes
intuitive sense.

(In reply to comment #2)
> Note that if you write it as (inserting an if statement):
<snip>
> it won't compile per the spec.

Maybe.  But is this really relevant?  Nobody's going to do this just to make
the compiler catch the error, since doing so would imply that the coder's own
eyes have already caught the error.


-- 



More information about the Digitalmars-d-bugs mailing list