Roslyn: !is Candy [Feature]

[RandyBuchholz]

With pattern matching coming, I've noticed the "is" operator being used in many examples. I've noticed the pattern (!(thing is null)) in a lot. A nice piece of candy would be to be able to apply "not" directly to the operator - (thing !is null). This would follow the comparison operator pattern for == and !=.

[svick]

A different solution to basically the same issue: if! https://github.com/dotnet/roslyn/issues/7927.

[whoisj]

@svick, hardly the same.

if! (<condition>) could be useful, but <var> !is <type> is far more flexible. Consider:

if (obj !is String && TryGetString(obj, out var str))
{

} else {
    var str = obj as String;
}

[alrz]

@svick That's basically guard (or unless) which has been discarded, which in turn, caused scoping changes for declaration expressions - https://github.com/dotnet/roslyn/issues/11562#issuecomment-237392081

[jnm2]

Also if! doesn't help when you're using x !is X without an if statement.

[HaloFour]

I move to make aint a keyword.

if (x aint Foo) { ... }

Kidding aside, I think I do recall another proposal for isnt or isnot.

While negation through a keyword isn't quite in the C DNA I think it would need to be one. Otherwise you get into parser weirdness and potential ambiguity, especially as ! has been proposed as a unary postfix operator for forcibly treating a nullable reference type as a non-nullable reference type.

[jnm2]

isnt

The informality and brevity kinda make me happy, but isnot is more likely. And now it matches VB. (yay?) I do prefer the keyword to be alphabetical only. It's easier to read. I'm so used to mentally parsing symbols and letters as separate tokens.

[alrz]

If we have a "negative pattern", it could be applied to whatever pattern that's appearing on rhs,

not-pattern:
 not pattern

Examples:

if(obj is not null)

switch(obj) {
  case not Enum.Constant:
      break;
}

It could be even nested in recursive patterns as well,

case (not 0, var y):
// equivalent to
case (var x, var y) when x != 0:

This would be consistent with other proposed pattern operators like #6235.

[RandyBuchholz]

I agree that we need a negative pattern and favor "not" syntax.

This suggestion though, is really just to add (why I used "candy") the ability to use "!" with "is" in simple comparisons. Essentially, the parser turns the (thing !is item) into (!( thing is item)) and continues. I see "!is" as less a new operator, and more of a pairing of existing operators that is expanded on parse. It's more of a visual thing than a functional thing that could possibly make it into C#7.0.

It just feels more consistent with ==/!=. But maybe "is" is less about equality and more about sameness. Question - is it correct to view "is" as "typeof(rhs) == typeof(lhs)?"

Re: non-nullable operator. Has ^ been considered? It's kind-of like "promoting" the type from nullable to non-nullable. ! seems strange, since it is often related to inversion or negation in most languages. It does make sense from the punctuation and CSS worlds where it implies importance. Though I don't know that a "promoted" thing is necessarily a more important thing... '^' doesn't have a presupposed meaning to most people.

[RandyBuchholz]

Oops... :)

[Joe4evr]

Re: non-nullable operator. Has ^ been considered? It's kind-of like "promoting" the type from nullable to non-nullable.

But then what does it mean to say "Dammit compiler^"?

Anyway, that operator is less about "promoting" from nullable to non-nullable, and more for suppressing the warning of potentially dereferencing a null variable (because it's all only static analysis anyway). And !. was chosen because it's a natural counterpart to the null-propogating operator ?..

[alrz]

This suggestion though, is really just to add the ability to use "!" with "is"

@RandyBuchholz Ok. I'll file a separate issue to not interfere with the discussion here.

[orthoxerox]

@HaloFour What about a yall keyword to call methods on collection members? :grinning:
c# var lastNames = yall customers.LastName;

[AdamSpeight2008]

Why not bring the isnot operator from VB.net over to C# as well?
Rather than have two chained operators, ( is ( not ( ___ ) ) It will also allows to in the future the option of checking against multiple types.

[jnm2]

@AdamSpeight2008 In VB.NET, x Is y means ReferenceEquals(x, y). In C#, x is y means typeof(y).IsInstanceOfType(x). Or in C# 7, it could also mean y.Equals(x).

Therefore, VB.NET's IsNot should mean !ReferenceEquals(x, y) and if C# gets isnot, it should mean !typeof(y).IsInstanceOfType(x). Or in C# 7, !Equals(y, x).

[AdamSpeight2008]

@jmm2 VB.net also has TypeOf obj IsNot t.

[jnm2]

@AdamSpeight2008 Yes, but that's not the IsNot operator, that's the TypeOf...IsNot operator which acts differently. If we bring the VB.NET IsNot operator to C# it would do !ReferenceEquals(x, y) when what we really want is either !typeof(y).IsInstanceOfType(x) or !Equals(y, x) depending whether y is a type or an instance.

[TonyValenti]

I would suggest using:
is!
Because then it reads as "is not" instead of "not is".

Other than that, I love this proposal.

[MgSam]

@HaloFour I think this was last discussed on CodePlex.

[Thaina]

I support this but I also prefer is!

[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 https://github.com/dotnet/roslyn/issues/18002. Comments and discussion about this issue can take place here or on an issue in the relevant repo.

I suggest that discussion on this issue can be continued on https://github.com/dotnet/csharplang/issues/27 or https://github.com/dotnet/csharplang/issues/246