Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Proposal] Labelled loops as targets for break and continue. #5883

Closed
orthoxerox opened this issue Oct 12, 2015 · 9 comments
Closed

[Proposal] Labelled loops as targets for break and continue. #5883

orthoxerox opened this issue Oct 12, 2015 · 9 comments
Labels
Area-Language Design Resolution-Won't Fix A real bug, but Triage feels that the issue is not impactful enough to spend time on.

Comments

@orthoxerox
Copy link
Contributor

Loop statements that are prefixed with a label can be the target of break and continue statements. break and continue can accept a single parameter that must be a label of an enclosing loop in the same method and apply to that loop instead of the innermost one.

Rationale: getting rid of the most common use of goto, restricting it to generated jump tables.

Rewritten example from C# reference (goto):

public class NoGotoTest1
{
    static void Main()
    {
        int x = 200, y = 4;
        int count = 0;
        string[,] array = new string[x, y];

        // Initialize the array:
        for (int i = 0; i < x; i++)

            for (int j = 0; j < y; j++)
                array[i, j] = (++count).ToString();

        // Read input:
        Console.Write("Enter the number to search for: ");

        // Input a string:
        string myNumber = Console.ReadLine();

        // Search:
        bool found = false;
        Search:
        for (int i = 0; i < x; i++)
        {
            for (int j = 0; j < y; j++)
            {
                if (array[i, j].Equals(myNumber))
                {
                    found = true;
                    break Search;
                }
            }
        }

        if (found) {
            Console.WriteLine("The number {0} is found.", myNumber);
        } else {
            Console.WriteLine("The number {0} was not found.", myNumber);
        }
        Console.WriteLine("End of search.");

        // Keep the console open in debug mode.
        Console.WriteLine("Press any key to exit.");
        Console.ReadKey();
    }
}
@antiufo
Copy link

antiufo commented Oct 12, 2015

I often felt the need of a break with label.
An alternate option is introducing a boolean variable, but this introduces an additional check at every iteration.
Otherwise, you can use a goto, but a break label would make things look prettier.

@MgSam
Copy link

MgSam commented Oct 13, 2015

So spelling goto as "break" makes it somehow better? It does exactly the same thing, no?

There's absolutely zero reason to be afraid of using goto statements to break out of loops in C#- they cannot jump between methods and this is their intended use.

@antiufo
Copy link

antiufo commented Oct 14, 2015

Yes but there's still some stigma associated to them
/s

@bondsbw
Copy link

bondsbw commented Oct 14, 2015

There is a slight semantic difference between break Search; and goto Search;. break would cause the labeled loop to be broken out of, while goto would cause the loop to start over.

The equivalent goto would place the label after the closing brace of the outer for loop.

One possible use for this syntax would be to create a rule disallowing the use of goto if your team feels that is appropriate, while retaining the ability to break out of nested loops or continue from within them.

@antiufo
Copy link

antiufo commented Oct 15, 2015

Yes of course you also have to move the labels. After the loop for break, at its end for continue. It might not be as intuitive as a break or continue.

@HaloFour
Copy link

It's funny, the negative stigma became attached to goto rather than the spaghetti code that it helped to facilitate. Now everyone avoids goto but is more than willing to write a rats nest in its place. In C# specifically I think that the stigma is misplaced as the compiler and CLR put pretty strict rules on where you can jump. It's not like the 50s or 60s when you could jump clear across the program to an arbitrary instruction. Dijkstra's editorial was written four years before c and he was largely repeating Zemanek's arguments from nine years prior to that.

goto is bad,mmmkay

That said, I don't think I've ever found a use for goto outside of explicit switch fall-through, and even that is pretty rare. For your use case I either refactor to a separate method and return once I've found the result I want, or I take advantage of the fact that for allows for multiple conditions:

bool found = false;
for (int i = 0; !found && i < x; i++) {
    for (int j = 0; !found && j < y; j++) {
        if (array[i, j].Equals(myNumber)) {
            found = true;
        }
    }
}

The one thing I don't really like about Java's implementation is that continue label; jumps to after the labelled loop which just looks kind of confusing. At least with goto you are jumping directly to the label.

@gafter
Copy link
Member

gafter commented Oct 21, 2015

Rationale: getting rid of the most common use of goto...

We don't have that as a goal.

@gafter gafter closed this as completed Oct 21, 2015
@gafter gafter added the Resolution-Won't Fix A real bug, but Triage feels that the issue is not impactful enough to spend time on. label Oct 21, 2015
@WrongBit
Copy link

WrongBit commented Nov 4, 2015

Why this proposal is closed?

@gafter
Copy link
Member

gafter commented Nov 4, 2015

Because the requested change isn't going to happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Language Design Resolution-Won't Fix A real bug, but Triage feels that the issue is not impactful enough to spend time on.
Projects
None yet
Development

No branches or pull requests

8 participants