[Proposal]: Support predicate negation i.e. !func

[kharai-tor]

The !expr currently works when the expr is a boolean. How about extending that to any boolean returning function? That way instead of writing this for example:

var xs = strings.Where(x => !string.IsNullOrEmpty(x));

this is what you'd write:

var xs = strings.Where(!string.IsNullOrEmpty);

I realize that this is very minor and maybe not worth the time it'd take to implement it. But I do find myself wishing for it from time to time so I thought I'd throw it out there.

[The-Futurist]

The !expr currently works when the expr is a boolean. How about extending that to any boolean returning function? That way instead of writing this for example:

var xs = strings.Where(x => !string.IsNullOrEmpty(x));

this is what you'd write:

var xs = strings.Where(!string.IsNullOrEmpty);

I realize that this is very minor and maybe not worth the time it'd take to implement it. But I do find myself wishing for it from time to time so I thought I'd throw it out there.

Perhaps related to this idea too: #91

[kharai-tor]

I can see how you drew a parallel between the two proposals but mine goes slightly beyond the linq example. You can store the result in other variables for example:

var isEven = (int x) => x % 2 == 0;
var isOdd = !isEven;

or use it with a function that accepts any number of arguments:

bool IsInRange<T>(T[] array, int index)
{
    return 0 <= index && index < array.Length;
}
var isOutOfRange = !IsInRange;

Now how useful any of that is, is of course an important question.

[HaloFour]

I wonder if something like this would fall out naturally with method group natural types and extensions:

public implicit extension PredicateExtension<T> for Func<T, bool> {
    public static Func<T, bool> operator !(Func<T, bool> predicate) {
        return x => !predicate(x);
    }
}

Currently you can't resolve extensions on a method group (otherwise you could write a Negate extension method today), but that could theoretically change.

[kharai-tor]

That works for methods with a single parameter. I guess you'd just list all overloads for each Func with a different arity in the BCL and call it a day. And that would get you 99.9% there probably even a 100% if you add overloads for functions with out and ref params whenever needed. Although I can't see when anyone would ever need that.

Would be cool if you could abstract over the function shape like you can in TypeScript:

function negate<T extends unknown[]>(f: (...args: T) => boolean): (...args: T) => boolean {
    return (...args) => !f(...args);
}

But that's a completely different conversation.

[HaloFour]

Indeed, cover a few arities of Func<..., bool> and you probably cover 99.999% of the use cases of this proposal. And this proposal is already pretty niche.