I see this isnt the place to submit feature requests, clsoing this.

@Korporal This is now the place to open discussion on feature requests, so you can reopen this if you want.

As suggested, I'm reopening this.

I like isnot or isnt and I dislike !is which has been suggested elsewhere. So many times I have to backtrack and prepend a ! and insert parentheses. This would be one of those day-to-day coding improvements for me. :)

Exactly, if the designers felt is necessary to add "is" supporting its converse seems like a natural step.

aint?

I would like is! more than isnot

And I would against isnt

Please don't add more keyword

It's really cringe inducing watching Mads' video on C# 7.0 and seeing if (!(o is int i)) return; as an example of a good coding pattern. isnot (or whatever you want to call it- I don't really care about the syntax) is painfully necessary.

Unrelated-
@Korporal Can you rename this to include the words "is not" in the title? It's hard to search for this issue as its currently written.

Related- Negetive pattern by @alrz

@Thaina: variable is ! Type might be confusing, people might easily mistake it for variable is Type ! (Non-Nullable-Reference) or might think it is used as an operator returning a boolean (or whatever an overload returns).

@phi1010 In my case I was differentiate between is ! and is!
What I mean is let is! without space as an operator by itself

is! without space OK?
Why you add space to make confusion anyway?
You surely be confused if you add space between it

What I propose is not to separate is and not as multiple operator
I propose that we should have operator is!
like == also have operator !=
You cannot have operator ! = you must have operator != without space

In many language they add operator by combine multiple symbol without space. Such as javascript === and !== symbol in addition to == and !=
They never make a bad choice such as == not or not == or ! == They must add !== without space so it never be a confusion

Unlike what you try to do is not and is !

@Thaina

Whitespace is an awful delineation of syntax. Not everyone programs using monospace fonts or with whitespace glyphs enabled.

@HaloFour I agree with you but the root cause itself came from Hejlsberg himself to select is as an operator. If we have symbol operator for is then put ! to it would be easy

I always feel wrong that we have word as operator instead of symbol. But now it's too late to argue about that

But in the same sense. While we cannot write varAisType. We must write varA is Type We must have whitespace there for is. Then it should be the same as is! and must write varA is! Type
In any font it will be the same whitespace so if anyone could confuse by the space of font he use for is then something must be wrong there

What is the relationship to #246 ?

@Thaina: The way the language is currently structured, I expect to be able to insert additional spaces at any position between two lexical tokens (literals, operators made of special characters, and words such as keywords, variables, method names, etc.).

It is somewhat obvious that it is not a good idea to separate a++; into a+ +;, but I (and maybe also silly text editors) expect to be able to insert spaces between letters and special characters. If there is currently a situation in C# where inserting spaces between letters and special chars is already invalid, please correct me, I can't think of any example.

@mattwar
The naming of the parameter can even help in an expression where they aren't assigned any value, just for the sake of verbosity on what 'int' and 'string' shall represent. Also there might be further null checks on those parameters later in the code or the variables default value is returned by the function. So I even see potential use for them in negated expressions.

@lachbaer you cannot use the variables in the code if they are never definitely assigned.

Well, there are two possibilities. 1st, ignore the identifiers completely ; 2nd assign the default value in case of a (negative) match. Btw, what happens with the variables of a standard pattern when there is no match and the scope is the enclosing block?

@mattwar I think the intent is that the negated pattern is precisely the negation of the normal pattern, so that for the expression e is not (int x, string y) both x and y are definitely assigned when false.

@gafter you are right. My mind was boggled by the negation and I couldn't think clearly.

@gafter

e is not (int x, string y) both x and y are definitely assigned when false.

Assigned to default values or assigned to the same values as if e is (int x, string y)? Because it can be seen both ways, either is not is the exact equivalent of !(. is .) - i.e. the variables are assigned as if the pattern was matching - or it is an expression of its own with a different outcome than the simple negation of the positive pattern, i.e. the variables are assigned with their type default values when the is not ... expression is true, and assigned with their deconstructed values when is not ... is false.

The latter makes a bit more sense to me, because that way is not is not ( 😀 ) just another way to write !(. is .) but has its own meaning. But you're deeper into that topic and may have different arguments?

Here's a list of possible usages of not:

1. if, while:

if not(xxx){}

while not(xxx){}

do {} while not(xxx);

There are many discussions of this feature:

• #157: Proposal: not keyword for if and while
• #560: Proposal: Add 'Unless' conditional statement, as seen in Ruby
• #562: Poll: until in addition to while
• #568: Proposal/Discussion: Negation of if/while Condition

Basically I vote for HaloFour's opinion in #568, allowing negation prefix operator ! to appear outside of the required parenthesis, this looks clean and simple. But if other usages make not a necessary keyword, I think it is not a big problem to let not work with if and while too.

2. is:

if (a is not xxx){} //-> if not(a is xxx){}, same to `while`

var notok = a is not xxx;

Actually as you can see, is not can be converted to if not or while not when used with if or while, but the not is still necessary when you just want to store the result to a variable.

3. switch:

switch (obj) {
    case Euro(var amount): [...]
    case USDollar(var amount): [...]
    case not LocalCurrency: [...]    // it's not Euro, nor USDollar, but is a currency: skip this block
    case decimal: [...]
    default: [...]
}

• earlier comment of @lachbaer

This is useful when we want to filter a specific derived type among multiple ones.
The equivalent for now is:

switch(creature) {
    case Animal a when !(a is Cat): [...]

//with `not` we can write this:

    case not Cat: [...]
}

The use of not effectively reduced keystrokes and the code became more clear.
But weak point still exists: we can filter only ONE derived type.

switch(creature) {
    case Animal a when !(a is Cat || a is Dog || a is Fish): [...]

//with `not`, some other enhancement must be done to filter multiple derived types:

    case not Cat Dog Fish: [...]
//or
    case not Cat, Dog, Fish: [...]
//or
    case not Cat not Dog not Fish: [...]
//or
    case not Cat nor Dog nor Fish: [...]
//or
    case not Cat || Dog || Fish: [...]
//or
    case not Cat | Dog | Fish: [...]
}

Looks like the 1st or 2nd solution is most acceptable:

• no repeated same keywords(3rd): a bunch of same not appearing in one single line will drive obsessives mad lol :D
• no new keyword(4th): although 'nor' makes statement closer to natural language, but introducing one more new keyword is an expensive cost, not as good as the 3rd solution.
• no new usage of current operator(5th, 6th): someone reads || and | as 'or', similar to the 4th solution, but the cost is expensive too.

The difference between 1st and 2nd is, the using of comma makes code more intuitive to read.

So, giving up support filter multiple derived types or make another enhancement, we have to face one.

One more question of using not with switch is, should not work with Enums and value types?

switch(weekday) {
    case DayOfWeek.Monday: [...]
    case not DayOfWeek.Sunday, DayOfWeek.Saturday: [...] //workday besides monday goes here
}

void foo(int number) {
    switch(number) {
        case 10: [...]
        case int k when k > 20: [...] //I have words to say about this `int`... XD
        case not 1, 3, 4: [...] // 2, 5-9, 11-20 goes here
        default: [...] // 1, 3, 4 goes here
    }
}

4. catch:

try
{}
catch (AnimalException ex) not CatException
{}

//or, for filtering multiple derived Exception types:

catch (AnimalException ex) not CatException, DogException
{}

In my opinion, try/catch is another specialized switch statement of Exception handling, so if not is necessary for switch, it should be necessary for try/catch.

There is a notable question is: the filtered Excetption types MUST be derived from which was caught. The compiler can make a check of this.

Think about this:

//Exception -> AnimalException -> CatException
//Exception -> ArgumentException -> ArgumentNullException

try
{}
catch (ArgumentException ex) not AnimalException
{}
catch (ArgumentException ex) not CatException
{}

Since an ArgumentException is definitely not an AnimalException nor a CatException, the not clause become meaningless here.

Of course there is equivalent for now, using when clause:

try
{}
catch (AnimalException ex) when (!(ex is CatException))
{}
catch (AnimalException ex) when (!(ex is CatException || ex is DogException))
{}

5. where (Generic type constraints):

A new idea of not or a new usage of !, and it seems there is not an equivalent present.

static class MyExtensions
{
  public static void AsSomething<T>(this IEnumerable<IEnumerable<T>> arg) { }
  public static void AsSomething<T>(this IEnumerable<T> arg) { } where T : not IEnumerable<> // <-- use of not constraint
//or
  public static void AsSomething<T>(this IEnumerable<T> arg) { } where T : !IEnumerable<> // <-- use of ! constraint
}


// Resolves to AsSomething<T>(this IEnumerable<IEnumerable<T>> arg)
new[] { new[] { 1 } }.AsSomething();

// Resolves to AsSomething<T>(this IEnumerable<T> arg) { } where T : IEnumerable<>
new[] { new { FirstName = "Joe", LastName = "Smith" } }.AsSomething(); 

• #707: Allow 'not' generic type constraints

Hi @qaqz111
Your proposal is more complicated for the compiler and sometimes might be confusing. The simple not operator, which would be an opposite of is operator, would be enough.

1, 2: Conditional operators and loops

if (x not string) sounds more natural than if not(x is string). And with if not operator you can do nonsense like this: if not (x not string).

3. Pattern matching

For pattern matching it is confusing and not helping at all.

object x = 1.0;
switch (x)
{
    case int i: break;
    case not double d: break;
    case not string s: break;
    default: break;
}

For the double value the execution will continue in the case not string s branch and the type of the variable s would be Object.

4. Exception filters

There is no need to invent another syntax for exception filters. Existing syntax will work and look completely fine:

catch (Exception ex) when (ex not OutOfMemoryException)

5. Generic type constraints

Generic type constraints are helpful when you need to know how you can use a constrained object. How can this constraint help you use variable obj?

void Foo<T>(T obj) where T : not String

Here's a list of possible usages of not:

1. if, while:

if not(xxx){}

while not(xxx){}

do {} while not(xxx);

Why don't we just add do {} until like vb? it's much more understandable IMHO.

do
{
    // stuff
}while(!(someBoolExpr))

do
{
    // stuff
}until(someBoolExpr)

There's already a propsal exploring: if !(xxx) { } and while !(xxx) { } and do { } while !(xxx);

Here's a list of possible usages of not:

1. if, while:

if not(xxx){}

while not(xxx){}

do {} while not(xxx);

Why don't we just add do {} until like vb? it's much more understandable IMHO.

do
{
    // stuff
}while(!(someBoolExpr))

do
{
    // stuff
}until(someBoolExpr)

Indeed, once again I refer to PL/I

do while (condition);
     /// statements
end;

do until (condition);
     /// statements
end;

But C# cannot undergo huge grammar changes at this point (no language could).

As mentioned above:

There's already a propsal exploring: if !(xxx) { } and while !(xxx) { } and do { } while !(xxx);

I've got a PR on an low-impact impl-strategy, and Aleksey is championing the feature.

@sleepyboyy your comment was in violation of our CoC and was deleted. Any such future violations will result in a ban. We value your interaction, as long as it is courteous and productive. If you'd like to discuss, you can contact us at conduct@dotnetfoundation.org

This is a bit useful, but not very useful