PSA: rejecting duplicate loop labels


#1

In order to future-proof potential future changes to the language, I am currently planning to add a static check to the compiler that will reject code that uses the same label multiple times within a single function body.

(The motivation for this is to future-proof support for using such labels as a way to identify code-extents explicitly, for use with a &'a expr expression form; currently borrow-expressions cannot be given an explicit lifetime, but that may change in the future.)


In particular, code like this will start to be rejected at compile-time:

fn foo() {
    'a: while test() {
        'a: loop { ... more stuff ... }
        ...
    }
}

while code like this will continue to be accepted:

fn bar() {
    'a: while test() {
        fn baz() { 'a: loop { ... more stuff ... } }
        ...
    }
}

This is obviously a breaking change. My hope is that it will not break too much code, but I have not yet attempted to evaluate the actual scope of the breakage.

If you have a strong opinion on the matter, feel free to voice it here.


See also discussion here, which documents my original (less aggressive) block-local plan for change here, and the problem with that plan:


#2

I didn’t even realize duplicate loop labels was valid. I’m guessing that this change will impact very little code.


#3

I’m assuming this would also disallow having a loop label with the same name as a lifetime bound?

For example:

fn hi<'a>(s: &'a str) -> &'a str {
    'a: loop {
        break 'a;
    }
    return s;
}

#4

No, I did not go that far.

(Maybe I should have…; let me go skim over how niko did those hard-errors on lifetime shadowing)


#5

Ok, just checking that. It seems like if in the future loop labels would be allowed as lifetime bounds, they wouldn’t want to conflict with existing lifetime bounds as well.


#6

Yes, I ended up revising the Pull Request to treat lifetime names in scope as conflicting with labels as well (and vice-versa) – i.e. basically the recent change to make lifetime-shadowing a hard-error has been strengthened to also reject shadowing of/by labels.

Thanks for the note, it was a good catch.