loop statement equivalent to while (true)

[Rekkonnect]

C# currently only offers loops that are bound to specific operations, while which breaks once the condition isn't met, for which provides a handy initialization and incrementation syntax sugar, and foreach which iterates over collections.

I've found myself using while (true) almost exclusively in certain scenarios, because most of the times the conditions to break are complex and would only be more problematic if I had to integrate it inside the condition. Many are the times that the breaking condition is in the middle of the looped body, meaning your best option is to evaluate the condition in its place and manually break the loop.

Rust provides a loop keyword and supports a native construct for while (true) and would feel more intuitive to type, as the developer is then asked to manually break the loop inside the body on demand without accounting for one special condition that's declared in a point above.

[Richiban]

The loop keyword in Rust isn't there just because it's shorter, it's there because certain features require knowing that the code is executed at least once (definite assignment analysis, etc) so there would have to be the same advantages in C# to make such a feature worthwhile. Simply having a syntactic shortcut for while (true) isn't going to cut it, I don't think.

[Rekkonnect]

while (true) is the same as a do while (true)

[FaustVX]

@Rekkonnect
Not exactly,
The second one means the loop will be executed at least once.

[sharwell]

while (true) also means the loop will be executed at least one.

[FaustVX]

Ok, I'm so dumb,
In my head, I thought of while (cond) vs do … while (cond)
Sorry for that.

[Korporal]

The loop keyword in Rust isn't there just because it's shorter, it's there because certain features require knowing that the code is executed at least once (definite assignment analysis, etc) so there would have to be the same advantages in C# to make such a feature worthwhile. Simply having a syntactic shortcut for while (true) isn't going to cut it, I don't think.

The Ada language too has a loop keyword, used alone it represents a true, infinite loop.

[jnm2]

See also #2475 for conditionless while

[FaustVX]

You can use the while loop with a condition

var myComplexCondition = true;
while (myComplexCondition)
{
    …
    if (…)
        myComplexCondition = false;
    …
}

[Rekkonnect]

My original proposal already addresses that situation and its whole purpose is to simplify this workaround down to creating a loop construct that solely relies on the developer manually breaking it inside its body.

[jnm2]

@FaustVX It's worth pointing out that this behaves differently than breaking in the middle of the loop, which is what this proposal was comparing to.

[FaustVX]

@jnm2 Yes, I didn't think of that.
I rarely break in the middle of a loop.

[TonyValenti]

Doesn't this do what you want?

for (;;) { 
   //body here            
}

[CyrusNajmabadi]

it was not quite intended to be used like that.

It definitely was intended for use in that way. The spec makes it clear that all parts are optional, and what the semantics are for when a part is or is not there: https://github.com/dotnet/csharpstandard/blob/standard-v6/standard/statements.md#1294-the-for-statement

This loop syntax and semantics were taken from our C lineage, where this behavior was known and intended as well. It was quite intentional for it to work this way.

You may want a syntax with less tokens. That's certainly a totally reasonable request to make. But it's not the case that existing idioms were not intended for his purpose :-)

[Rekkonnect]

It definitely was intended for use in that way.

In the C# world, yes. It would otherwise cause compilation errors. In the C world though, you had while for a standard conditional loop, and for for a loop that initialized and incremented values per iteration. You had the option to (ab)use for (;;), but it was avoided in favor of while (1).

Now, allowing for (;;) in the first place in C is a design decision, which should not happen if you wanted your language to not be "hacky" (bodge things till it works and make random exotic stuff work). C# took that initial design, no biggie. It's up to us to not use it, when we have while (true) which is easier to type and more quickly understandable.

[CyrusNajmabadi]

which should not happen if you wanted your language to not be "hacky" (bodge things till it works and make random exotic stuff work)

It's neither random, nor exotic. Every part of this construct is intentionally optional, with clear and sensible semantics about what it means when not provided. There are no hacks here.

You may personally find using such a construct undesirable, but that's a personal preference decision. Importantly, we don't use an individual's distastes to motivate adding redundant syntax.

[CyrusNajmabadi]

which is easier to type and more quickly understandable.

Both are idiomatic C#. The language has been in around and in development for around 25 years now. Replacing idiomatic things present in v1 is not a goal.

[Korporal]

Doesn't this do what you want?

for (;;) { 
   //body here            
}

True, @TonyValenti yet so does this:

repeat: 
   // body statement 1
   // body statement 2
goto repeat;

Inelegant though that it is, it doesn't even need braces and is somewhat more elegant than a for (;;) an utterly cryptic, bizarre way to express unbounded repetition, they could have at least allowed for() for such a case or even for ever, I mean we already have yield return so surely this would be trivial.

[Korporal]

C# currently only offers loops that are bound to specific operations, while which breaks once the condition isn't met, for which provides a handy initialization and incrementation syntax sugar, and foreach which iterates over collections.

I've found myself using while (true) almost exclusively in certain scenarios, because most of the times the conditions to break are complex and would only be more problematic if I had to integrate it inside the condition. Many are the times that the breaking condition is in the middle of the looped body, meaning your best option is to evaluate the condition in its place and manually break the loop.

Rust provides a loop keyword and supports a native construct for while (true) and would feel more intuitive to type, as the developer is then asked to manually break the loop inside the body on demand without accounting for one special condition that's declared in a point above.

It would be helpful to support a simple loop directive where the loop termination (if any) is handled by logic wholly in the loop body.

The reason we use contrivances like:

while (true)

or

for (;;)

Is because the language does not offer an unconditional looping structure/keyword.

If adding a new keyword to C#'s grammar was trivial we could just consider adding a new "loop" or "forever" keyword, it would be that simple, done, dusted:

loop
{
   a = do_stuff();

   if (a == b)
      break;
}

I've been designing an unrelated language grammar that has this, all loops are variants of "loop" with optional clauses for "while" and "until" and iterations and so on. A "loop" is effectively always infinite, unconditional, unless one includes additional clauses.

I don't think a suggestion for supporting a new simple way to express unconditional loops in C# is likely to go anywhere myself.

[spydacarnage]

If adding a new keyword to C#'s grammar was trivial we could just consider adding a new "loop" or "forever" keyword, it would be that simple, done, dusted:

As has been discussed in other threads, adding a new keyword is not trivial.

I don't think a suggestion for supporting a new simple way to express unconditional loops in C# is likely to go anywhere myself.

Based on the above non-trivial nature of adding the keyword, versus the benefit of being able to type loop instead of while (true), I think you are correct - I see no real benefit of this moving forward.

You could even write an analyzer to make sure there is a break statement inside a while (true) loop if you want to ensure that.

[CyrusNajmabadi]

If adding a new keyword to C#'s grammar was trivial

From a technical standpoint, adding a new keyword is trivial. The downside is the complexity gain to the language/community/ecosystem. In order to take on that sort of change, we need to believe that the benefit will be worth it there.

Is because the language does not offer an unconditional looping structure/keyword.

Correct. The language (and designers) does not think it needs to offer a targeted solution in-lang for all situations. If we believe a scenario is handled just fine by existing solutions, then that will often be fine with us. In other words, we think it's better for the language to have a smaller set of features, which can be used for a broader set of scenarios, even if that means that some scenarios don't have an absolute 'minimal' solution for that particular need.

I don't think a suggestion for supporting a new simple way to express unconditional loops in C# is likely to go anywhere myself.

Feature requests are assessed based on the value they bring, against the downsides they incur. This very much includes not wanting the lang to feel like a kitchen sink where everything has been thrown in. Given that our back-compat guarantees are extremely high, this means that we would certainly have all of the same keywords as before, and now would have this one as well. This would make things more complex, while not really improving things substantively for users.

[HaloFour]

I also firmly believe that loops without a condition should be slightly more painful to write so that the developer properly considers what they intend to do.

[CyrusNajmabadi]

@Korporal as mentioned in prior conversations (and even mentioned literally directly above). This is not a matter of grammar design. Extending C# to support this is trivial. The question is whether extending the language in this way is a good idea or not. Currently, the philosophy of C# is that limiting such extensions and making extremely judicious choices where we do extend is the best thing for our ecosystem. I've marked your post off-topic as it is not actually about this suggestion, and seems to be a meta-point about something unrelated. Please keep things on-topic. Here, that would be about if such an extension has enough value to outweigh the problems we think may also some with it.

Note: this applies to other discussions as well. Popping into discussions to lament about how you think the grammar should have been designed isn't going to fly here. This was previously contained to #5311, but didn't seem to be constructive, and it was locked. That's not a pass to then leak the same stuff out into unrelated discussions about other future language features.

I think we would allow a dedicated discussion thread by you on hte topic of the C# grammar and the design decisions there. Such questions and opinions would be fine in the context of that discussion, if we can keep it primarily on C# and not have it bleed out elsewhere. Feel free to create such a discussion if you would like. It would also be fine to bring these off-topic conversations to Discord (discord.gg/csharp) to discuss with the team and community there. Discord is much more free-form, where all sorts of conversations and topic flows are totally acceptable. CSharplang discussions need to stay on topic though. Thanks!

[Korporal]

@Korporal as mentioned in prior conversations (and even mentioned literally directly above). This is not a matter of grammar design. Extending C# to support this is trivial. The question is whether extending the language in this way is a good idea or not. Currently, the philosophy of C# is that limiting such extensions and making extremely judicious choices where we do extend is the best thing for our ecosystem. I've marked your post off-topic as it is not actually about this suggestion, and seems to be a meta-point about something unrelated. Please keep things on-topic. Here, that would be about if such an extension has enough value to outweigh the problems we think may also some with it.

Note: this applies to other discussions as well. Popping into discussions to lament about how you think the grammar should have been designed isn't going to fly here. This was previously contained to #5311, but didn't seem to be constructive, and it was locked. That's not a pass to then leak the same stuff out into unrelated discussions about other future language features.

I think we would allow a dedicated discussion thread by you on hte topic of the C# grammar and the design decisions there. Such questions and opinions would be fine in the context of that discussion, if we can keep it primarily on C# and not have it bleed out elsewhere. Feel free to create such a discussion if you would like. It would also be fine to bring these off-topic conversations to Discord (discord.gg/csharp) to discuss with the team and community there. Discord is much more free-form, where all sorts of conversations and topic flows are totally acceptable. CSharplang discussions need to stay on topic though. Thanks!

May I respond to your remarks about me?

Read the OP, it suggests adding another way, a new way to express a non terminating loop to the language, that actually isn't trivial with C# (despite your claims to the contrary) and I think that mentioning this and the reasons for it is pertinent to the discussion, hence me saying what I said.

[Korporal]

@Korporal Based on several of your posts in this repo over the past few days (and in the past), i think you're operating under several misunderstandings and misapprehensions about how the language is designed (especially the grammar), and how it impacts potential future lang features. I would highly recommend either creating a discussion on that topic, or coming to discord (discord.gg/csharp, Roslyn channel) to discuss this matter further. We can help clarify this area, which will help many of your future conversations on this repo.

There really isn't anything to "clarify", admittedly in the case under discussion the grammar would support:

loop
{
}

and have no backward compatibility consequences from what I can see, so yes in this specific case it is easy, I was wrong. In general though adding new keywords does present challenges as Lippert's piece explains and as this post too explains.

So I have the clarity, thank you.

[CyrusNajmabadi]

In general though adding new keywords does present challenges

IN general, changing any language can present challenges, depending on what the change is :) All languages will have design choices that will impact what sorts of changes you can make, and what sorts of things are simple, what sorts of things are complex, and potentially what sorts of things are near impossible.

In c# though, it tends to be pretty simple teh vast majority of the time to make these sorts of grammar changes. Occasionally, albeit very rarely, there are harder challenges. Only twice though have we had to do anything complex to support these things. And the second time we learned from the first, and took an approach that greatly reduced that complexity, making only marginally more difficult than any other sort of normal change here.

explains and as this post too explains.

These posts dive deep into these topics to share info for curious and enthusiastic readers about the rare cases that do arise. They are not a conveyance about the general case.

[CyrusNajmabadi]

@Korporal as before, general posts about your feelings around the c# grammar are off topic fort specific discussions.

I have laid out what is allowed on csharplang. This includes making a dedicated post on this topic (but keeping it on C#). You are also welcome to discuss this matter on many of our other communities. Further discussions of the general grammar design and how you perceive it will not be permitted in specific discussions. Thanks!

Specific posts on the grammar here are fine. Going off onto tangents about the grammar in general are not.

[Korporal]

So, going back to the beginning of the thread (i.e. looping!), what could be the objection to adding

forever
{

}

to the C# language? It's trivial to do, that's been established, is simpler than for(;;) or while(true) and surely better than:

repeat_what_I_just_did:
   do_stuff();
   do_more_stuff();
goto repeat_what_I_just_did;

(despite several recent recommendations to leverage goto more when we can) I mean what is the downside here? really?

[CyrusNajmabadi]

Yes, you do like to keep saying "idiom".

Yes. As both fred and i have mentioned, these forms are idiomatic and that is relevant to our decision making. I'm not sure what else to tell you here. You're welcome to think that such a think isn't relevant, or should be weighed differently. Your feelings and opinions on this are certainly valid.

Wrt to the term 'idiomatic', i'm using the following definition:

using, containing, or denoting expressions that are natural to a native speaker.

The forms you've mentioned above are completely natural to the C# community. They are the trivial version of those constructs applied to the trivial case. They are simple, understandable, and have broad acceptance. You are totally free to believe that they are not sufficient and that a specialized construct be present to support this trivial case as well. However, currently, no members of the C# language design group appears to agree with that view, and prefers the status quo where the existing constructs continue to be used in the same fashion as they have for 25 years. Perhaps something will change here in the future. But for now, that's the state of things. I'm sorry if that's not palatable to you and your desires for the future of the language.

Finally, wrt to the rest of the post, please keep things civil and constructive. The team has made no secret of the things it considers important, and these views and approaches have been what have directed the development of the language since v1. If you have issue with that, then perhaps this isn't the best tool for you. If you are interested in participating in the development of it though, then understanding how the team views these things is relevant and will continue to be part of the process, just as it always has been. Thanks!

[CyrusNajmabadi]

@Korporal Further meta discussion about the design process around C# and the weights and balances the team gives to aspects of that design should be put into a different discussion. This discussion should only be on the topic of 'loop' (or similar solutions to the concept of providing an alternative to while (true)).

[HaloFour]

@Korporal

You've been invited many times to join the Discord server if you want to have further discussions along those lines. You've chosen to ignore that and to continue to argue here.

The terms are inequitable because you are not a language design team member. This isn't a democracy. Proposals aren't going to be accepted based on winning arbitrary logic games, nor are they going to be accepted based on your badgering over logic flaws.

C# loosely follows C philosophies which follow UNIX philosophy, which is to have simpler composable pieces that can be combined to solve larger problems. Adding a loop or forever keyword that only satisfies a single and relatively uncommon use case directly contradicts those philosophies. The fact that this use case can already be satisfied through the combination of existing language features and that these approaches are idiomatic by virtue that they have been the documented approach for doing so for the past 50 years in the C ecosystem makes it further unnecessary. There is no friction in the language here, and trying to reduce from two tokens to one in a situation that might occur once, if ever, in any given program, is not a goal of the language.

[CyrusNajmabadi]

I mean what is the downside here? really?

It's pretty much the same reasoning that came up with the elsif discussion. A new way do to do something already easy and idiomatic. It's practically no upsides and many downsides.