-
Notifications
You must be signed in to change notification settings - Fork 1k
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/Discussion: Negation of if/while Condition #568
Comments
I give it 👍 because I believe that it improves reading and thinking much. The downside is that it can be easily overlooked compared to if! (foo is Bar bar) ...
if ! (foo is Bar bar) ...
if !(foo is Bar bar) ...
// worst:
if !
( foo is Bar bar ) ... foobar! 😁 Of all I prefer the @HaloFour style. (Hey, good name, "the HaloFour condition syntax" 😇 ) |
I prefer the readability of |
A little side note: though they are kind of obsolete for this case, an a priori negated condition could call the |
I disagree, that would prevent no spaces: if!(foo is Bar bar) which is less common but is used. |
@jnm2 agreed with Both situations would need to consider how pattern variables should work, scoping, etc. |
I'm pretty meh on this. I don't think the readability is any better with the removal of the outer parenthesis (I see it that way, not moving the not operator out). And if the readability isn't improved, ergo, there's no good reason to do it (IMO). I think the biggest issue here is that It also opens the door for other things to be included outside the parenthesis (by precedent), which I think will ultimately have a detrimental effect on the language long-term. |
Rather than this, i would just prefer that we relax the grammar for if we did that, then Currently the requirement of parens is simply a holdover from C. There is no actual syntactic need/ambiguity it addresses. Which construct this is is already governed by the leading keyword. -- Another way to think about this is the grammar was always |
Indeed, that is another option. I probably wouldn't prefer that syntax in the normal cases, but it does enable the syntax above as well. Personally I like the parenthesis and I apply them generally anywhere that I might have a non-trivial expression, such as with |
If you championed that, @CyrusNajmabadi, I'd be more than happy to promise to never ever again argue with you or make snide comments about the motives and behaviour of the team. Deal? 😀 |
#itsatrap |
I would do it... if i believed you :D |
Does this mean that one liners such as this:
Would be legal? When separating on multiple lines, the syntax looks OK, but when on the same line, it starts to get all jumbled together. At least that's my perception. This becomes a stylistic issue though, I don't see any real drawback to having this. Note, I don't see any benefit, but like I said, it's stylistic, and may be of benefit to others (and I acknowledge saving people from having to type millions of parenthesis over their lifetime). |
Yes
Then don't write it that way. :) It's not like parens would be disallowed. They would just not be required. Similar to how we don't require curlies. It's up to you if you want to mandate them for your own code or not depending on situation. |
Someone didn't read the rest of my response =P |
Exactly! Like the placing of curly braces or so many other different things. A common style will establish nevertheless, one that is primarily teached in books. But then you should also allow |
if !foo.Bar() foo.Baz(); Meh. |
I predict pattern matching complications if this is ever legal. if obj is Foo foo foo(); |
Knew it wouldn't be long. Ambiguity: if obj is Foo foo (x).Bar();
|
Well, very obviously the use of a statement-block must be forced in case the condition parentheses are dropped. Not a big drawback, because most flow statements I see around have braced statement blocks anyway. Another advantage to me is, that it makes one-line if obj is null { return; }
// vs.
if (obj is null) { return; } The second is normally spread over 4 lines in total, I guess that that coding style exists, because two clasped regions in one line is "ugly". With only one braced block however it plays in the same leage as other used constructs. public Student(string Name, int Age) : base(string Name) { _age = Age; }
string Name { get; private set; }
if foo is null { bar(); } (First one has other |
Every |
C# is rife with ambiguities :) The only rules are:
c# 1.0 shipped with this ambiguity:
|
@lachbaer You said:
But you then referenced a construct that has two clasped regions in one line. You said that that was ok though because you'd seen that construct many times. But, of course, if it's ok because you've seen it many times, then certainly a multi-clasped 'if' on a single line is ok because you'll have seen |
@CyrusNajmabadi I thought it was very obvious what I wrote. But especially for you:
|
If removing the need for the condition parantheses, what is a big change for a B/C-derived language since their existence, then IMO the enforcement of a braced statement-block for that new syntax should also be introduced. |
This seems like one step forward, one step back. :) |
I understand what you mean, but sometimes a step back isn't a bad step if you're at the edge of an abyss 😀 I mean, you once wrote that you primarily focus on features for educated programmers. Most advanced code that I have seen use statement-blocks always anyhow (we're talking about control statements here). With this change you had the unique possibility to write history and shift it for the better, for the sake of clarity to all developers.
Even if you resolved the amiguities by definition, there is the chance that other developers meant it differently. Why introducing a just possible trap when you can avoid it in the first place? Hasn't C# a leading paradigm of avoiding errors before they occur? |
that's a fair point. But i don't think it's our place to mandate that sort of thing at the language level. i think it would be much more appropriate to just give users style options in the IDE so they can decide on stylistic things themselves. For example, i have to accept that people that want this, will want to write: if (!(o is string))
return; And will want to convert it to: if !(o is string)
return; If we say "if you want to remove hte parens, now you have to write: if !(o is string)
{
return;
} Then that's going to kill the value of this feature for many users. |
Note: i'm not dismissing this concern. It would definitely be a deep one. But i would not consider it a killer for this idea. We would have to consider what we would do here, and it might entail carving out a set of allowed/disallowed things. I'm just trying to clarify that it's unlikely that we could introduce a code-reduction feature, and then tack on a required code-increase feature :D |
Once again, this is a job for a Roslyn Analyzer. You could make the case to include one with Roslyn/VS/ I think it would be strange to have @CyrusNajmabadi Is there any precedent etc. of creating a compiler warning or error from such an ambiguity as the one defined above, rather than quietly parsing it as one or the other? |
It is unfriendly for non English speakers to increase vocabulary |
How is that more unfriendly than |
|
I usually solve that problem with some refactoring. |
While I largely agree, that is substantially more verbose and does not work well when it comes to analysis for definite assignment and pattern matching. For |
It is unfriendly for non-English speakers to have an English-based language. But, as programmers, we get used to it. I'm sure you can deal with extra keywords, as might have been the case with, e.g., @HaloFour, thanks for explaining that. |
Absolutely not. I cannot imagine programming in Persian. that would probably read like Shahnameh by Ferdowsi. |
@alrz, I meant that as a very general comment. If you don't know any English, that would be unfriendly at first, but then you'd certainly get used to it. I agree with you, of course, I can't imagine working with a non-English based language. |
I find that in spoken language, This would make it more suitable for a Unfortunately, this makes for rather horrible readability IMO - for example, Ruby has statements such as: puts "This string will not be printed" unless true ... which trips me up every time. |
@jordao76 |
if (control.Validate()) { } // WinForms API
if (int.TryParse(s, out var n)) { } If TryParse… what? If it returns true. If its result is true. if (!(enabled && visible)) { } "If not enabled and visible" is not technically correct, "if not enabled or not visible" is not what is written. Correct reading is "If enabled and visible are not both true". Maybe native speakers can come up with a better option without be true/not be true/be not true, but I can't. |
Or "if not both enabled and visible." ‘Either...or’ works with any number. ‘Both...and’ only works with exactly two. I've tried to think of what you'd say for Speech doesn't lend itself to parenthesizing, in general. |
I don't try to convert to unparenthesized English. |
You can sort of express such logical expressions in English:
With the "," being vocalised as a slight pause. But such an approach quickly breaks down for non-trivial examples and is highly error prone. |
But it's not when |
@DavidArno That's a spoken equivalent of a whitespace-sensitive language! |
Ah, English, don't you just love it? 🤣 |
If it's not a bool, I couldn't read it at all. I would get stuck for a while trying to realize what does it mean, what was the intention and what is the difference between |
I prefer an |
I personally quite like the idea of negation of the statement. I tend to work with a lot of juniors, and something like this would make many simple boolean errors go away. |
Just wanna mention that if you remove parenthesis then you need to specify when the expression ends somehow. Either make block compulsory
You could |
I'd also love if negation operator |
I see where you are getting at but doesn't look great imo |
Or |
Or a if (isDone && foo.VeryLongMethodName().MyElement.GetList().Any().Not())
{
//do stuff
} |
Actually I think And it's not always give the exact same result with negation. |
There have been a couple of proposals exploring how improve the readability of conditional operations that involve negation. Some developers find the nesting of parenthesis to be unattractive at best and easy to miss at worst.
I would like to explore the potential of allowing for a negation prefix operator
!
to appear outside of the required parenthesis forif
andwhile
conditions so that the condition is effectively reversed:Certainly minor and the argument can definitely be made that the negation is even less obvious. It also doesn't address concerns with operators that would still require parenthesis, e.g.
is
.The text was updated successfully, but these errors were encountered: