Add labeled break and continue statements

[SPY]

Rendered.

[Dekkonot]

My preference would be to have the label follow the do I think, since it makes it more obvious that it's attached to that scope rather than just the loop. It also solves some of the ambiguity problems of less ugly syntax (my apologies to anyone who is in love with ::label::) because the position is already a syntax error with something as simple as a colon:

for i = 1, 10 do: label
  if i == 8 then
    continue label
  end
end

While I'm not strictly proposing this syntax (it gets weird due to e.g. do:label("foo"):lower()), it gives us more options than making it a prefix to the keywords.

repeat has the same property, which is that a lot of symbols after it are just outright syntax errors right now.

[bradsharp]

While this would be a nice feature I am not sure about the syntax to to add a label. Could we lean into attributes here with something like @label <name>? Alternately, could this be a number where break 1 is equivalent to break and break 2 would break the outer loop?

[nnullcolumn]

While this would be a nice feature I am not sure about the syntax to to add a label. Could we lean into attributes here with something like @label <name>? Alternately, could this be a number where break 1 is equivalent to break and break 2 would break the outer loop?

break 1 or break 2, albeit admirably minimal, seem like they could cause mistakes - e.g. moving nested code from one spot to another. Attributes historically haven't changed the runtime semantics of programs (apart from arguably native in niche float ways), so it feels bad to overload them for control flow. I like the solution dekkonot proposed even if it allows people to mangle their syntax a bit.

[SPY]

My preference would be to have the label follow the do I think, since it makes it more obvious that it's attached to that scope rather than just the loop.

I like it.

my apologies to anyone who is in love with ::label::

Never was attached to it. It looks ugly :)

[Nicant02]

I like this, something like this would be nice to have.

I enjoy the extended do block syntax, an uncommon pattern I do sometimes when I need to check a bunch of different things that chain off of each other is something like:

-- execution starts
repeat
	local character = Player.Character
	if not character then
		break
	end
	
	local humanoid = character:FindFirstChildOfClass("Humanoid")
	if not humanoid then
		break
	end
	ApplyDamage(humanoid, 10)
until true
-- execution continues

[InfraredGodYT]

My preference would be to have the label follow the do I think, since it makes it more obvious that it's attached to that scope rather than just the loop.

I like it.

my apologies to anyone who is in love with ::label::

Never was attached to it. It looks ugly :)

I was unsure about the syntax at first, but using do: label sealed the deal for me. If this isn’t too complex to add, it’ll definitely be a nice addition.

[alexmccord]

Even label: (do|for|while|repeat) and break label are syntax that can be supported retroactively. No need for ::label:: gunk or postfix kw: label. And quite frankly, I don't want to read for k, v in t do: label, I want to read label: for k, v in t do.

[nnullcolumn]

Even label: (do|for|while|repeat) and break label are syntax that can be supported retroactively. No need for ::label:: gunk or postfix kw: label. And quite frankly, I don't want to read for k, v in t do: label, I want to read label: for k, v in t do.

imo, label: for is crazy visual noise and looks like a type annotation in all the wrong ways

[SPY]

After internal discussion with the team we decided to split this PR in two moving away labeled do blocks.
The reason for that is potential inconsistency: do blocks going to support only labeled breaks, introduction of unlabeled breaks for do blocks breaks backward compatibility with code like:

for i in 1,10 do
  if i > 5 then do break end end
end

We still consider breaking labeled do blocks reasonable language feature, but we think it deserves own RFC.
If there is no significant objections for labeled loops/break/continue I'm going to merge that RFC next week

[nnullcolumn]

this opinion is orthogonal to my feedback, but in addition to many quality concerns (a lot of the wording here is excessively fluffy imo - llms are well known for that), i think merging an ai-generated rfc as-is sets a potentially antisocial precedent for future collaborators.

[nnullcolumn]

there should be a space before the parenthesized text here

[nnullcolumn]

i think 'a labeled form of loop', 'extend break and continue', 'label is written as a colon-suffix on the loop's do keyword', etc... are good things to communicate, but could be said more concisely by replacing this entire section with something along the lines of 'introduce named control flow manipulation in loops with do: label, repeat: label, break label, and continue label'

[nnullcolumn]

'commonly used' seems very subjective, there are lots of luau codebases without this pattern. perhaps 'may be used' would be better?

[nnullcolumn]

Label names must be unique within their immediately enclosing block.

this wording makes no sense to me. if the meaning is what follows it, why have this at all?

Redeclaring a label name at the same scope level is a compile-time error. Shadowing an outer label with an inner label of the same name is permitted, following the same rules as variable shadowing.

why a compile error for making the same label twice in the same scope? does this imply:

repeat: retries
    local ok, err = attempt()
    if err == "fatal" then break retries end
until ok or retries_exceeded()
-- invalid
repeat: retries
    local ok, err = attempt_other()
    if err == "fatal" then break retries end
until ok or retries_exceeded()

if so, that seems extremely different from local shadowing semantics - those scopes are completely unrelated, since the label stops existing as soon as you leave the loop. secondly, there already exist lints for shadowing locals. i'd argue if anything we should lint or compile error the opposite way - inner shadowing disallowed because it results in rules which may be significantly more confusing, but otherwise there should just be no limitation imo

[nnullcolumn]

This is straightforward but must be carefully specified to avoid edge cases at line boundaries.

could this be explained further? i don't really see how this results in any edge cases, and line boundaries feel orthogonal

[nnullcolumn]

Since continue only appears inside loop bodies and cannot start a function call, there is no ambiguity with expression statements.

this sentence doesn't make a lot of sense. why would a keyword start a function call, and how is that related? additionally, expressions and statements are fundamentally disjoint in luau - there are no expression statements. there are things which are valid as expressions and valid as statements, but to me this paragraph seems really unnecessary generally?

[nnullcolumn]

that doesn't make a lot of sense, you say it has no implications and then explain how it behaves in control flow analysis. isn't non-local jumping from an inner loop an inherently more complicated control flow which wasn't possible before? even the drawbacks section addresses this directly.

the behavior here is also worded somewhat confusingly explaining the implications of this, possibly because it seemingly ignores potential implications

[nnullcolumn]

space missing before parenthesized section here

[nnullcolumn]

perhaps the CLOSEUPVALS bytecode should be mentioned in the drawbacks section? a vm developer would have to tell me if that's super significant because idrk the implementation of that

[nnullcolumn]

although i'm not against a very exhaustive drawbacks section, i'm not sure this item is very significant. it could also be merged with the later one that talks about the learnability of this syntax.