Allow while loop without parentheses for function

[Thaina]

Sometimes I need to write

while(true)
{
    if(!SomeFunction())
        break;
}

while(true)
{
	var still	= await SomeFunctionNeedToHaveCallBack(() => { // Task<bool>
		//// Long code

		if(someCondition1)
			return true;

		//// Long code
		if(someCondition2)
			return false;

		//// Long code
		return true;
	});

	if(!still)
		break;
}

With the normal while syntax it not go well with formatter

while(SomeFunction())
    ; // the formatter would try to put body here and sometimes cause warning

while(await SomeFunctionNeedToHaveCallBack(() => { // Task<bool>
		//// Long code

		if(someCondition1)
			return true;

		//// Long code
		if(someCondition2)
			return false;

		//// Long code
		return true;
	}))
	; // the same and also with unneccesary indent for the body

If it would be a function I think it safe to let while body be empty and don't need to wrap parentheses around it. Because the condition in question is up to the returned value

I think it could be better if I could write it as this

while SomeFunction();

while SomeFunctionReturnInt() > 0;

while await SomeFunctionNeedToHaveCallBack(() => { // Task<bool>
	//// Long code

	if(someCondition1)
		return true;

	//// Long code
	if(someCondition2)
		return false;

	//// Long code
	return true;
});

Which is also made it intentionally differ from normal while loop that should require body
It should prohibit normal condition

while false; // ERROR

int x;
while x > 0; // Also ERROR

bool b;
while b; // Also ERROR

[svick]

I don't think this situation is common enough to warrant special syntax.

Especially since the main motivation seem to be "the formatter doesn't behave the way I like".

[Unknown6656]

What about using:

while (SomeFunction())
    continue;

It is a bit more typing than just an "empty" semicolon body, but I find it to be a bit more readable for external readers....

[HaloFour]

When exploring whether or not parenthesis could be removed from if statement conditions it was determined that it led to a number of situations where the code could be ambiguous to the compiler. I imagine that the same problem would exist here.

[Austin-bryan]

while Foo(); is much cleaner than while (Foo());, I will admit, but I guess it might not be possible, given what @HaloFour mentioned.

[The-Futurist]

@willard720 - Unfortunately C# has a grammar that is based on the more primitive C language (and later C++ then Java). The grammar can't (easily) be changed without introducing breaking changes and eliminating parentheses is an example.

I've always been disappointed when "new" languages (like Java was and C# is) emerges that actually conform to the grammar of a much older and more primitive language.

I've mentioned before the PL/I language and its superb grammar that has no reserved words and does not need the silly parentheses we see all over the place in C#.

Of course PL/I too is old now but the C# designers could have started with a true clean sheet of paper and designed a new grammar that avoided this antiqued syntax.

Here are some of the silly things forced upon us by this grammar

• We have to use == for compares! (we could easily use just = if the grammar had been designed right).
• We have to wrap expressions in ( ) for many constructs.
• We have to fully qualify names even when a partially qualified name is unambiguous when parsed/resolved.
• We have many reserved words that a) prevent these words being used for variables and b) prevent the language designers from adding new keywords without breaking existing source.

[Austin-bryan]

@Korporal

the silly parentheses we see all over the place in C#

C# doesn't have any compared to other languages, like Lisp, and there's very few places where we can even remotely discuss removing them. Control keywords, being one, and casting could've been foo.To<Bar>(); or something.

We have to use == for compares! (we could easily use just = if the grammar had been designed right).

That would actually be very confusing as they are not the same thing. Also, people coming from C/C++ know never to do if (x = 4) because that will evaluate to 4 and not to what x was beforehand. People are already used to using = and == so this would cause much confusion.

We have to wrap expressions in ( ) for many constructs

And? Alternative? How do I write (5 + 3) * 6 without ()? (Note, 8 * 6 isn't the point, the point is telling the compiler which operations I want to happen first.)

We have to fully qualify names even when a partially qualified name is unambiguous when parsed/resolved.

No? That's not true. You can just use a using statement. And it's probably for the best that it defaults to needing the using statement because that could cause ambiguity later. It's not even complicated to add, you just type the type, hit ctrl +. and it adds it for you...

We have many reserved words that a) prevent these words being used for variables and b) prevent the language designers from adding new keywords without breaking existing source.

C# does have a lot of keywords, yet 1/3 ish of them are contextual. Most of the reserved words I never would need to name something anyways, except for char, so I just use c instead. C# is also adding new keywords as well, but their contextual so they don't break code. Also, what's your solution to this? Should all keywords just be symbols instead?

C# may have flaws, yet you didn't even point any of the good ones out, nor did you even give any ideas for solutions. Another thing is that C# used the "antiqued" and "primitive" language syntax for a reason. People are familiar with it. Both C and C++ are two of the greatest and most widespread languages used and have lasted decades. Seems like a good idea to follow their syntax. That's why so many big and widespread languages are classified as C-like languages.

Something you're missing is that if C# had drastic changes that broke what people were familiar with, like using only =, C# likely wouldn't've ever been successful. People would've tried it, not liked it, then stopped using it and stuck to the things they were familiar with so you'd never even been able to complain about it's base syntax, especially when it wasn't created by a famous company.

Edit:

Also, if you want to use a keyword, you can use @ in front of it, such as:

public int @public = 2;    // this works

Other people will no what it means, so you don't need some convention like using an underscore _public which might mean something else in a different convention.

[Thaina]

@svick In my opinion the formatter is something solidated from people's convention and familiarity. It make people could see the unintentional code. So the problem with formatter with some perfectly fine logic hint that it will not comfortable unless it be officially support

Not to mention that empty body while loop would cause warning. All in all I think the problem is syntax of while does not designed to use in this pattern at the start. And it actually a good thing that it normally don't permit empty body and long condition

So I think the best option is having a syntax to intentionally loop and condition in the same block. It decrease unnecessary indented block too

alternatively, There was a do keyword

do SomeFunction(); // without while

do await SomeAsyncFunctionWithCallBack(() => {
    await SomeTask();
    return false;
}); // without while

[The-Futurist]

@willard720 - I never said there were no reasons for the C# grammar being what it is, I simply pointed out things that I find undesirable in that grammar and the undue 'homage' it pays to C, a feeble (though popular) language with feeble grammar.

As for reserved words, you misunderstand why PL/I has no reserved words. It did not do that to encourage programmers to name things after keywords (which they can) but to allow the language designers to introduce a new keyword at any time and have zero risk of breaking existing source code IF there was code out there that happened to use the new keyword for an identifier.

[CyrusNajmabadi]

None of this part of the discussion si relevant. C# is what it is. It's in the name. It was very intentionally and explicitly chosen to continue the lineage of C-style languages. I'm sure there are communities that would be happy to discuss the relative merits of different languages (and their descendants), but it doesn't have a place in the discussion of this specific feature request.

[The-Futurist]

@CyrusNajmabadi - The discussion began to discuss the C# grammar (be altering the syntax in some places) so I don't see why you object to us discussing the C# grammar!

[CyrusNajmabadi]

I'm pointing out the metadiscussoin about the choices of C# that were made decades ago are not helpful. Issues are not here to re-litigate that stuff.

Specifically, this part is what is unhelpful and doesn't further the conversation for this issue:

I've always been disappointed when "new" languages (like Java was and C# is) emerges that actually conform to the grammar of a much older and more primitive language.

I've mentioned before the PL/I language and its superb grammar that has no reserved words and does not need the silly parentheses we see all over the place in C#.

(and much of the rest htat followed that)

[The-Futurist]

@CyrusNajmabadi - You are speculating, how do you know that these few posts do not or will not "further the conversation"? By censoring these informal discussions you run the risk of stifling innovation. If you don't find this or that post helpful or useful then so what? move on.

[HaloFour]

@Korporal

Bringing it up repeatedly when there is nothing that can be done about it doesn't do anything to further the conversation.

[CyrusNajmabadi]

@CyrusNajmabadi - You are speculating, how do you know that these few posts do not or will not "further the conversation"?

Lamentations on the decisions made by C# two decades, which will absolutely not be changing any time soon (and will definitely not be changing due to posts in some random issue) are not helpful. They're a distraction. If you want a conversation about the decisions here and how they made be changed, they should be in a different issue. This is the issue about syntactic-changes to loop-statements. It's not the general "i'm bummed about what C# did in the past, let me bring it up and complain about it, even though that will have no impact here" issue.

[The-Futurist]

@HaloFour @CyrusNajmabadi - I think you'll find I've submitted TWO posts in this thread about the C# grammar, one of these was a response to @willard720, so the statement "bringing it up repeatedly" is to say the least, a stretch of the truth.

Stop behaving like an elitist clique for goodness sake, I've said what I said and responded to someone's reply, you guys are wasting far more time and energy on berating me than anything I posted.

I'm done with this thread now, it's quite juvenile in here at times.

Later.

[HaloFour]

@Korporal

I think you'll find I've submitted TWO posts in this thread about the C# grammar,

And three other times on this repository:

#1530 (comment)
#1619 (comment)
#83

[Unknown6656]

I'm just going to throw in my opinion, while we're at it.

@Korporal : I am not sure, whether your behaviour is very useful. I can see your point and I understand your arguments for some of the proposed features, but they are mostly going against the C# core design guidelines or are not backwards-compatible.

I think that your argument of C# being "old-fashioned" is partially valid -- but an argumentation with PL/I is in this context IMO completely ridiculous. I haven't use PL/I before (so I cannot really judge it), but upon first glance it looks closer to some old-fashioned BASIC, PASCAL or ALGOL with way to many keywords......
(Yeah, I know that there are no real keywords in PL/I, but using procedure .... end still goes into that direction -- unlike { ... })

I hope that you get the point, that I am trying to make here: I do not want to attack you or PL/I, but I think that in sense of "cleanness", PL/I would be a step backwards from C#. If you want to fork C# and integrate some PL/I features into it -- by all means - do it! It is a wonderful idea!
However, I do not think that it is an appropriate change for the main C# language.

Besides, being "old-fashioned" must not always be negative: Look at Haskell, it is an old language, but by far one of the best in terms of flexibility, type-safety and cleanness. Haskell has been such a great inspiration, that Microsoft even decided to create F# as new language based upon it (and on OCaml).

---

This aside - please do consider that @CyrusNajmabadi and @HaloFour are very experienced members of the .NET community and attacking them as some "elitist clique" or "arrogant" is not at all productive. Did you consider, that they may have the best interest of C# at their hearts and have more experience of the evolution of language features than either of us?

[The-Futurist]

@Unknown6656 - Please be logical and read what has been written not what you think has been written. You've completely misunderstood what I wrote about PL/I. I am not advocating it at all, I simply gave it as an example of a grammar that has no reserved words.

You're also confusing keyword with reserved word hence you've misunderstood all that was written.

Finally some here do indeed communicate as members of an elitist clique, I see it often on the internet with some technical people who feel they are special, ego is never far away sadly.

[HaloFour]

@Korporal

Please be logical and read what has been written not what you think has been written.

Please be polite to other community members.

As for this whole "clique" thing, I don't think that it's at all inappropriate to call out that you have been repeatedly (yes, repeatedly, as in four separate times on this repository) making unconstructive statements regarding the intentional design of the language. You may disagree with that design and the lineage set forth for the C# language but this is not the place to litigate it, nor will ANYTHING come of it. C# is not going to be redesigned to be another language. You already know this. Complaining about those 20 year old decisions will not change anything. Nor will they advance any of the proposals where you've felt the need to bring this up. Your opinion is entirely valid and I share it in some aspects of the language, but it's not doing you any favors to berate the ghosts of language design past.

[Unknown6656]

@Korporal

Please be logical and read what has been written not what you think has been written
You're also confusing keyword with reserved word hence you've misunderstood all that was written.

Then do please enlighten me -- what is in your opinion the difference between the following:

• A contextual keyword, such as var, async, .....
• A reserved word
• A keyword

I was under the impression, that a keyword can either be:

• static -- and thus forbidden in function or variable names
• or contextual, such as some in C# are -- and all in PL/I (if I got it right).

Do please note that you can use a static keyword as a variable name in C# if you prepend it with the at-symbol (@).

Edit №01:

By "difference" I mean:
What is the effective difference between a reserved word and a (contextual or static) keyword on the resulting code and the semantic (for the reader/coder)?

[The-Futurist]

@Unknown6656 - I'll leave it to the forum police to berate you for making unhelpful posts here. I wonder though if you'll get the same treatment I did...

Then do please enlighten me -- what is in your opinion the difference between the following:

A contextual keyword, such as var, async, .....
A reserved word
A keyword
I was under the impression, that a keyword can either be:

static -- and thus forbidden in function or variable names
or contextual, such as some in C# are -- and all in PL/I (if I got it right).
Do please note that you can use a static keyword as a variable name in C# if you prepend it with the at-symbol (@).

[Unknown6656]

@Korporal : You really are a funny guy^^