Date: Fri, 17 Feb 2023 15:09:43 +0000
-------- Originalnachricht --------
Betreff: Re: [std-proposals] Proposal regarding labeld breaking and
continuation
Datum: 17.02.2023 16:08
Von: hypatia.sva_at_[hidden]
An: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Hello Arthur,
Yes, you are in fact correct, it is just a goto. The idea behind the
proposal is to have a "scoped goto" so that I can turn off goto in the
compiler and only allow the named breaks/continues.
In the proposal, it does describe it as a goto. I dont think I did
anything to obstruct that, it says it should act "as if" it is one.
There is actually a small difference:
label: { ... goto label; ... }
leaves the scope, and then reenters it.
label: { ... continue label; ... }
is equivalent to
{
label: .... goto label;
}
and therefore never leaves the scope. I dont know if any compiler would
actually execute any destructors on the first example, but Im sure it
doesnt happen on the second one, because the scope is never left.
Its also imo just part of the semantics of a continue to not leave
scope. With the goto, I have to make sure of that myself, have to add
another line etc. I think that isnt really necessary for such an obvious
pattern.
In regards to the old proposals, I only found this:
https://lists.isocpp.org/std-proposals/2020/03/1179.php
But there was no document attached, so I assumed thats why it didnt go
anywhere.
I also didnt find any explicit dismissal about it, so I assumed it was
either just ignored or never seriously proposed. Are there any other
things you are aware of that dont show up on my search?
I dont have a lot of experience with the comittee, and I wrote this
mostly to see how well the markup, standards reference etc hold up, so I
might have missed something big, but the search on the mailing list
didnt yield anything particularly helpful.
Hypatia of Sva.
Am 17.02.2023 15:56 schrieb Arthur O'Dwyer:
> On Fri, Feb 17, 2023 at 9:51 AM Hypatia (of) Sva via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello,
>>
>> Actually, I had an example of that. The algorithm was the Smith normal
>> form of an integer matrix, and I had to add / subtract columns from
>> each
>> other until the gcd was in the pivot position a[i][i]. The short form
>> of
>> the algorithm is like this:
>>
>> First, Make sure a[0][0] isnt 0; if the whole matrix is 0, return,
>> otherwise swap columns / rows
>> The main loop: subtract the first column/row from the others as much
>> as
>> possible while staying positive (so subtract the column a[i][0] idiv
>> a[0][0] times). If for any now a[i][0] or a[0][i] is smaller than
>> a[0][0] (i.e. a[i][0] % a[0][0] > 0), then swap the columns, _and
>> begin
>> the loop again_!
>> This means, inside the loop going over the rows / columns, you have to
>> restart, effictively you have
>>
>> for(;;)
>> outer: {
>> for(row: rows) {
>> transform();
>> if(necessary) {
>> swap_rows(row,0);
>> continue outer;
>> }
>> }
>> //the same with columns.
>> }
>>
>
> I don't quite understand this code.
> - If `continue outer;` means "continue the `for (row: rows)` loop,"
> then
> it's equivalent to `continue;`.
> - If `continue outer;` means "continue the `for(;;)` loop," then it's
> equivalent to `goto outer;`.
> Either way, it seems that we have a dedicated syntax for this already.
>
> I don't think this proposal is worth pursuing anyway (I encourage you
> to
> google "labeled break continue C++ proposals" to see all the older work
> in
> this area). But if anyone *were* amenable to being convinced by a
> single
> example, it seems to me that this wouldn't be the example to show them
> —
> because (unless I'm misunderstanding the intent of the code) this is
> actually a perfect example of C++'s existing syntax sufficing just fine
> in
> practice. It seems to show the exact *opposite* of motivation for this
> proposal.
>
> –Arthur
Betreff: Re: [std-proposals] Proposal regarding labeld breaking and
continuation
Datum: 17.02.2023 16:08
Von: hypatia.sva_at_[hidden]
An: Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
Hello Arthur,
Yes, you are in fact correct, it is just a goto. The idea behind the
proposal is to have a "scoped goto" so that I can turn off goto in the
compiler and only allow the named breaks/continues.
In the proposal, it does describe it as a goto. I dont think I did
anything to obstruct that, it says it should act "as if" it is one.
There is actually a small difference:
label: { ... goto label; ... }
leaves the scope, and then reenters it.
label: { ... continue label; ... }
is equivalent to
{
label: .... goto label;
}
and therefore never leaves the scope. I dont know if any compiler would
actually execute any destructors on the first example, but Im sure it
doesnt happen on the second one, because the scope is never left.
Its also imo just part of the semantics of a continue to not leave
scope. With the goto, I have to make sure of that myself, have to add
another line etc. I think that isnt really necessary for such an obvious
pattern.
In regards to the old proposals, I only found this:
https://lists.isocpp.org/std-proposals/2020/03/1179.php
But there was no document attached, so I assumed thats why it didnt go
anywhere.
I also didnt find any explicit dismissal about it, so I assumed it was
either just ignored or never seriously proposed. Are there any other
things you are aware of that dont show up on my search?
I dont have a lot of experience with the comittee, and I wrote this
mostly to see how well the markup, standards reference etc hold up, so I
might have missed something big, but the search on the mailing list
didnt yield anything particularly helpful.
Hypatia of Sva.
Am 17.02.2023 15:56 schrieb Arthur O'Dwyer:
> On Fri, Feb 17, 2023 at 9:51 AM Hypatia (of) Sva via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
>
>> Hello,
>>
>> Actually, I had an example of that. The algorithm was the Smith normal
>> form of an integer matrix, and I had to add / subtract columns from
>> each
>> other until the gcd was in the pivot position a[i][i]. The short form
>> of
>> the algorithm is like this:
>>
>> First, Make sure a[0][0] isnt 0; if the whole matrix is 0, return,
>> otherwise swap columns / rows
>> The main loop: subtract the first column/row from the others as much
>> as
>> possible while staying positive (so subtract the column a[i][0] idiv
>> a[0][0] times). If for any now a[i][0] or a[0][i] is smaller than
>> a[0][0] (i.e. a[i][0] % a[0][0] > 0), then swap the columns, _and
>> begin
>> the loop again_!
>> This means, inside the loop going over the rows / columns, you have to
>> restart, effictively you have
>>
>> for(;;)
>> outer: {
>> for(row: rows) {
>> transform();
>> if(necessary) {
>> swap_rows(row,0);
>> continue outer;
>> }
>> }
>> //the same with columns.
>> }
>>
>
> I don't quite understand this code.
> - If `continue outer;` means "continue the `for (row: rows)` loop,"
> then
> it's equivalent to `continue;`.
> - If `continue outer;` means "continue the `for(;;)` loop," then it's
> equivalent to `goto outer;`.
> Either way, it seems that we have a dedicated syntax for this already.
>
> I don't think this proposal is worth pursuing anyway (I encourage you
> to
> google "labeled break continue C++ proposals" to see all the older work
> in
> this area). But if anyone *were* amenable to being convinced by a
> single
> example, it seems to me that this wouldn't be the example to show them
> —
> because (unless I'm misunderstanding the intent of the code) this is
> actually a perfect example of C++'s existing syntax sufficing just fine
> in
> practice. It seems to show the exact *opposite* of motivation for this
> proposal.
>
> –Arthur
Received on 2023-02-17 15:09:46