Proposal: Compose boolean MethodGroups

[dmartensson]

Compose boolean MethodGroups

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Be able to compose a method group out of multiple boolean methods accepting the same single argument.

Motivation

We often use the linq syntax .Where(IsRed) to filter lists but I often also run into cases where I need all but the red or need to test more than one condition.

But IsNotRed is not a nice method name and many times we use existing methods so either we have to create a method for the inverse or use a full lambda .Where(o => !IsRed(o)). I think this is common enough to warrant a way to do boolean composition. It reads much easier.

So that we could write

.Where(!IsRed && IsAvailable)

instead of

.Where(o => !IsRed(o) && IsAvailable(o))

or

bool IsNotRed(NN n) => !IsRed(n)

.Where(IsNotRed)

Detailed design

This could be accomplished by a rewrite step in the compilation
Turning
.Where(!IsRed && IsAvailable)
into
.Where(o => !IsRed(o) && IsAvailable(o))

But of cause at the AST tree level or similar

Since it will be restricted to methods accepting the same single argument and returning bool it should fit right in with the method group feature

Drawbacks

The only thing I could think of is it adds a new syntax, but I think its obvious enough for anyone anyway.

Alternatives

Listed under motivation

Unresolved questions

I cannot think of any.

Design meetings

[YairHalberstadt]

Why do you feel this is such a common operation that it is worth special casing in the language? I certainly have combined boolean methods in a lambda before, but I've done lot's of other things as well, and I'm not sure why I would expect a whole new language construct for this particular use case?

To put it another way, the language provides a few raw constructs to enable you to to do pretty much everything with them. Then for the cases which are particularly common, or very error prone, it provides extra constructs to allow you to do this more easily/error free. This case is neither particularly common, nor very error prone, so adding a language feature seems like it wouldn't meet the extremely high bar set for new language features.