if! syntax for if not

[Thaina]

Most of the times we do any not logic. It very messy

To add parentheses just for add ! in front of all logic
Or empty if then else
Or cache a bool

It very surprising that there is no easy way to make shorthand easily

So I want to propose if! syntax

var dict = new Dictionary<string,object>();

object obj;
if(!dict.TryGetValue(key,out obj) || !(obj is string)) //// normal syntax
    DoSomethingToAddNew(key);

if(!(dict.TryGetValue(key,out obj) && obj is string)) //// parentheses
    DoSomethingToAddNew(key);

if!(dict.TryGetValue(key,out obj) && obj is string) //// my proposed
    DoSomethingToAddNew(key);

[HaloFour]

Here's some relevant CodePlex conversation on this subject:

http://roslyn.codeplex.com/discussions/570681

[am11]

An extra +1 if Ruby's unless is preferred over if!. Otherwise 👍 for your proposal.
Once upon a time, I tried to propose a similar thing for XNOR (iff) effect: http://roslyn.codeplex.com/discussions/541739.

[asvishnyakov]

I think you need white spaces before if, so instead of new if! syntax they just need allow ! before parentheses in if statement:

if (!dict.TryGetValue(key,out obj) || !(obj is string)) //// normal syntax
    DoSomethingToAddNew(key);

if (!(dict.TryGetValue(key,out obj) && obj is string)) //// parentheses
    DoSomethingToAddNew(key);

if !(dict.TryGetValue(key,out obj) && obj is string) //// my proposed
    DoSomethingToAddNew(key);

I don't know why ! allowed before parentheses in other cases (like var isString = !(obj is string)) but not allowed in if.

[HaloFour]

@asvishnyakov Because the parenthesis that follow the if keyword are a required part of that control statement and an expression must be contained within. This is true for most control statements. When it comes to just normal expressions you can always wrap them in parenthesis and that has an effect of forcing precedence, although in your example the result is the same.

[Thaina]

@asvishnyakov as @HaloFour said so I would like it to be keyword if! or iff or ifn

So if you normally use space before parentheses then it would be if! () instead of if !()

Because the problem will arise when you write one line if

if (true) DoSomeThing(); //// I don't like this but many people use it
if !(true) DoSomeThing(); //// Will be ambiguous that !(true) is for if or not

[HaloFour]

A keyword containing a punctuation character, especially a unary operator, is likely a parsing nightmare. Adding any keyword for this seems way overkill considering that the problem is already so easily solved, even if a few people find the syntax unsavory.

At best I could see perhaps consideration for using the unary negation operator for conditions in control statements such as if or while, in which case if !(x == y) { } would be valid and equivalent to if (!(x == y)) { }. But even that seems like more work than necessary to solve a non-problem.

[Thaina]

@HaloFour It don't seem like a problem when you write a short logic

[HaloFour]

@Thaina At the very worst you have to wrap the Boolean expression in parenthesis. It's far from a problem. The c family of languages has survived just fine without a separate negated conditional statement.

[Thaina]

@HaloFour Wrapping long logic in parentheses just for negate logic that's a problem in source code. tracking logic is harder. less obvious and difficult to manage

[HaloFour]

It's strictly a question of taste. Most languages, like the c family of languages, don't have a dedicated negated conditional statement. It's simply not needed. There's not a single use case here that can't be solved with existing syntax and two additional characters.

[Thaina]

@HaloFour If we have no taste we don't need to use C# or even C. We could just use assembly. We can solve any problem with assembly

[alrz]

Removing parentheses from if syntax (just like Swift) would solve your "problem" but as for negative is (#7465), chances are zero to none.

[asvishnyakov]

@Thaina, @HaloFour If they allow ! operator before parentheses, we will be able use it not only in if, but in while statement too. If they declare new operator if!, they need declare while! too and duplicate all “if-like” operators in future.

[HaloFour]

@asvishnyakov If they did permit placing a ! before the parenthesis with the parsing rules of C# that should still allow for the ! to appear immediately following the if with (or without) a space between the ! and the parenthesis, so the net effect would be the same:

// all legal
if!(expression) { }
if! (expression) { }
if !(expression) { }
if ! (expression) { }

[asvishnyakov]

@HaloFour, Yep. Yet another reason to allow ! before parentheses instead of declare new if! statement.

[Thaina]

I would like it to have only one correct syntax so I'm convinced that it should just allow ! just before any boolean parentheses

So it should allow just
if!()
and
if !()

Which is fine by me bacause I will just use if!()

[bondsbw]

public int Square(int x) => x * x;

also doesn't solve any problem, if readability isn't a problem. I consider readability to be a big consideration, so I support this proposal.

[asvishnyakov]

👍

[gafter]

We are now taking language feature discussion in other repositories:

• https://github.com/dotnet/csharplang for C# specific issues
• https://github.com/dotnet/vblang for VB-specific features
• https://github.com/dotnet/csharplang for features that affect both languages

Features that are under active design or development, or which are "championed" by someone on the language design team, have already been moved either as issues or as checked-in design documents. For example, the proposal in this repo "Proposal: Partial interface implementation a.k.a. Traits" (issue 16139 and a few other issues that request the same thing) are now tracked by the language team at issue 52 in https://github.com/dotnet/csharplang/issues, and there is a draft spec at https://github.com/dotnet/csharplang/blob/master/proposals/default-interface-methods.md and further discussion at issue 288 in https://github.com/dotnet/csharplang/issues. Prototyping of the compiler portion of language features is still tracked here; see, for example, https://github.com/dotnet/roslyn/tree/features/DefaultInterfaceImplementation and issue 17952.

In order to facilitate that transition, we have started closing language design discussions from the roslyn repo with a note briefly explaining why. When we are aware of an existing discussion for the feature already in the new repo, we are adding a link to that. But we're not adding new issues to the new repos for existing discussions in this repo that the language design team does not currently envision taking on. Our intent is to eventually close the language design issues in the Roslyn repo and encourage discussion in one of the new repos instead.

Our intent is not to shut down discussion on language design - you can still continue discussion on the closed issues if you want - but rather we would like to encourage people to move discussion to where we are more likely to be paying attention (the new repo), or to abandon discussions that are no longer of interest to you.

If you happen to notice that one of the closed issues has a relevant issue in the new repo, and we have not added a link to the new issue, we would appreciate you providing a link from the old to the new discussion. That way people who are still interested in the discussion can start paying attention to the new issue.

Also, we'd welcome any ideas you might have on how we could better manage the transition. Comments and discussion about closing and/or moving issues should be directed to #18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I think dotnet/csharplang#157 is probably the best place to continue discussion on this request.