Date: Thu, 19 Dec 2024 06:42:48 +0100
> I look forward to seeing N3377 soon in WG14, and hopefully adding it to C2y.
I think that's reasonable. Personally, I think we can have our cake
and eat it too. We can simply change how labels work, by tying them to
a scope and letting you reuse them.
"goto" would still be able to defy scope, and every occurrence of
"goto" that exists right now would keep working. However, if the user
wrote "goto duplicate", where "duplicate" has been used twice in the
same function, this would be ill-formed because the jump target would
be ambiguous.
In my opinion, it is much better to keep the existing syntax for
labels and simply update the wording around them a little bit so they
interoperate more nicely with break/continue. The same can be done on
the C2y side as on the C++26 side.
If EWG sees this proposal in Hagenberg, it would be nice to get a vote
for "we want this feature" at least, even if we haven't agreed on a
specific syntax yet, and it remains to be seen if N3377 is accepted.
However, I also don't see the existing "label:" syntax as so unusable
that we cannot proceed with it.
I think that's reasonable. Personally, I think we can have our cake
and eat it too. We can simply change how labels work, by tying them to
a scope and letting you reuse them.
"goto" would still be able to defy scope, and every occurrence of
"goto" that exists right now would keep working. However, if the user
wrote "goto duplicate", where "duplicate" has been used twice in the
same function, this would be ill-formed because the jump target would
be ambiguous.
In my opinion, it is much better to keep the existing syntax for
labels and simply update the wording around them a little bit so they
interoperate more nicely with break/continue. The same can be done on
the C2y side as on the C++26 side.
If EWG sees this proposal in Hagenberg, it would be nice to get a vote
for "we want this feature" at least, even if we haven't agreed on a
specific syntax yet, and it remains to be seen if N3377 is accepted.
However, I also don't see the existing "label:" syntax as so unusable
that we cannot proceed with it.
Received on 2024-12-19 05:43:01