Champion "range patterns"

[gafter]

• Proposal added
• Discussed in LDM
• Decision in LDM
• Finalized (done, rejected, inactive)
• Spec'ed

The idea is to have a pattern with a syntax like

range_pattern
    : 'in' constant_expression 'to' constant_expression
    ;

Which matches input primitive values that are >= the first constant expression and <= the second constant expression.

An alternative is to have relational patterns, which would be a pattern like <3:

relational_pattern
    : relational_operator constant_expression
    ;
relational_operator
    : '<'
    | '>'
    | '<='
    | '>='
    ;

I (@gafter) think I prefer the alternative of relational patterns, especially in conjunction with pattern combinators like and.

[yaakov-h]

Why use a new syntax here, a to b, and not range syntax, a..b? Is this to allow for the feature to work with custom operators?

[CyrusNajmabadi]

aren't range exclusive? (and they're a value, not a pattern). This wants to be inclusive right?

[alrz]

If we ever get inclusive ranges, I'd expect the same syntax for range patterns.

[YairHalberstadt]

For floats, how would you match exclusively?

[CyrusNajmabadi]

Wouldn't inclusive/exclusive always be about if you're doing <= vs <?

[YairHalberstadt]

Yep, so it's useful to be able to pick.

[qrli]

The old dilemma

double v = 1.0;
switch (v) {
  case in 0 to 1.0: Good(); break;
  case in 1.0 to 2.0: NotSoGood(); break;
  default: break;
}

[alrz]

you'd probably get a subsumption error for that?

[jveselka]

I think there should be both in x to y with inclusive upper bound and in x until y with exclusive upper bound.

[orthoxerox]

@alrz but how would you avoid it?

[Richiban]

Is there also a way to create a System.Range with this syntax?

I really think that one of the overall goals of putting patterns into C# should be construction/deconstruction symmetry.

I know that this is case in rather than case, but I still think that's it's part of the same language feature that I should be able to write:

var r = 1 to 10;

Because, currently, if I want the range of numbers from 1 to 10 I will have to write

var r = 1..11;

which makes me shudder.

[tpetrina]

Why not just be explicit about it:

switch (x)
{
 case 0 <= a < 1: // ...
 case 1 <= a: // ...
}

This can play nicely with custom types as well.

[alrz]

but how would you avoid it?

@orthoxerox 1.0 + Double.Epsilon to 2.0 could work, but as far as I know, F# Rust doesn't allow exclusive range patterns, probably because it's not that useful in practice (and might be confusing).

[Thaina]

I don't see any difference between .. and to but I want to have only 1 syntax here. If we would write .. for a range I would like it to be that syntax for range pattern and vise versa, if we use to for range pattern I think we should also use to for range object

But then again we actually could use when so range pattern is not much useful? It also not ambiguous between inclusive and exclusive

case int i when i > min && i <= max:
break;

[YairHalberstadt]

One advantage of the range pattern is it makes it easier for the compiler to verify that all cases have been dealt with.

[HaloFour]

So, assuming and patterns are also implemented, we'd be able to do something like the following?

var letterGrade = gpa switch {
    > 3.0            => "A",
    > 2.0 and <= 3.0 => "B",
    > 1.0 and <= 2.0 => "C",
    > 0.0 and <= 1.0 => "D",
    _                => "F"
};

An alternative is to have relational patterns, which would be a pattern like <3:

I <3 it too.

[alrz]

@HaloFour I don't think we should complicate the most common use case (inclusive range) just to support any possible combinations of operators?

In case you want to simplify multiple case labels to a range pattern, you don't really want to worry about >=, <= and other operators.

I'm not against relational patterns (although I expect less usefulness vs. say user-defined patterns) but I think range patterns would be still useful when you just want a simple range match.

[Thaina]

@alrz I think simple range is not actually simple. We need to remember its half open behaviour and thus we could confuse sometimes. Relational patterns always make it obvious for everyone include newbie even it a little more verbose

[alrz]

@thania "range patterns" as originally proposed here are inclusive, and they are that way in every language I checked. there's nothing to be confused about when you say you can rewrite case 0: case 1: ... case 9: to case 0 to 9 or something.

[Thaina]

@alrz Sure but as of we discussed so long. I think now we should drop the original range pattern and encourage the relational pattern as alternative range pattern instead

[MkazemAkhgary]

@alrz Sorry but ranges in matlab are inclusive but in python are exclusive (half open).

[Thaina]

After I see a relational pattern. I have imagine that, what if we allow pattern as a shorthand for Func<T,bool>

Today we write

int[] items;
items.Where((item) => item >= 0 && item < 10);

Maybe we could

int[] items;
items.Where(>= 0 and < 10);

More than that

int?[] items;
items.Where({}); // not null pattern
SomeObject[] objs;
objs.Where({ value: >= 0 and < 10 }); // obj has field value and obj.value >= 0 && obj.value < 10

[Joe4evr]

@Thaina #91.

[Thaina]

@Joe4evr That's right. But only allowing pattern as Func<T,bool> even it was more limited but it make this shorter and also covered just the most common use case

items.Where(@ >= 0 && @ < 10);
// vs
items.Where(>= 0 and < 10);

[HaloFour]

@Thaina

It's a single character difference, and I disagree that it's the most common use case. I posit that LINQ/EF against POCOs are the most common use case.

[ghost]

I wrote This in #2268
While I am reading this example in Docs:

static string Quadrant(Point p) => p switch
{
    (0, 0) => "origin",
    (var x, var y) when x > 0 && y > 0 => "Quadrant 1",
    (var x, var y) when x < 0 && y > 0 => "Quadrant 2",
    (var x, var y) when x < 0 && y < 0 => "Quadrant 3",
    (var x, var y) when x > 0 && y < 0 => "Quadrant 4",
    (var x, var y) => "on a border",
    _ => "unknown"
};

I wondered if it can be shorter and more readable to achive the purpose of pattern matching, so I suggest this:

static string Quadrant(Point p) => p switch
{
    (0, 0) => "origin",
    (> 0, > 0) => "Quadrant 1",
    (< 0, > 0) => "Quadrant 2",
    (< 0, < 0) => "Quadrant 3",
    (> 0, < 0) => "Quadrant 4",
    (_, _) => "on a border",
    _ => "unknown"
};

@HaloFour siad this proposal would achieve this, so I am a fan :)

[munael]

This is a special case of 'Active Patterns' (which we don't have and I can't find a proposal for them).

I'd rather have active patterns in the language, and some helpers in the library.

static string Quadrant(Point p) => p switch
{
    (0, 0) => "origin",
    (GT(0), GT(0)) => "Quadrant 1",
    (LT(0), GT(0)) => "Quadrant 2",
    (< 0, < 0) => "Quadrant 3", // With custom operators (orthogonal feature) [1]
    (GT(var x, 0), LT(var y, 0)) => $"Quadrant 4: x: {x}, y: {y}", // `GT` et al. are (overloadable) patterns.
    // the `pat(var x)` form lets the pattern expose a value/ref through a new name
    // while other expressions are just passed as if arguments to a function.
    (_, _) => "on a border",
    _ => "unknown"
};

If we ever get custom operators, we get exactly the proposed syntax ([1]) for free. The features are then separate.

[jho1965us]

FWIW in asn.1 you can specify both inclusive, exclusive and half open ranges the syntax seem to work pretty good.
inlusive ranges this way:

min..max

exclusive this way

min<..<max

half open excluding max

min..<max

half open excluding min

min<..max

[TheFanatr]

To keep the dots in order to make range-related syntax consistent, I'd propose the following options.

Change Current Meaning and Extend With Colons

Channel C#'s Inner Python

1..3 = (1, 3)
:1..3: = [1, 3]
:1..3 = [1, 3)
1..3: = (1, 3]

Change Current Meaning but Keep Dots

1..3 = (1, 3)
.1..3. = [1, 3]
.1..3 = [1, 3)
1..3. = (1, 3]

Keep Current Meaning and Extend With Dots

1..3 = [1, 3)
1..3. = [1, 3]
1...3 = (1, 3)
1...3. = (1, 3]

Keep Current Meaning and Extend With Colons

Channel C#'s Inner Python but More Wack

1..3 = [1, 3)
1..3: = [1, 3]
1:..3 = (1, 3)
1:..3: = (1, 3]

The formal mathematical equivalencies are displayed after the equal signs. The colons or extra dots essentially act as range endpoint augmenters, pulling the range endpoint in the metaphorical left or right direction for more strict or less strict on the left and less strict or more strict.

Example with First Option

Default

Syntax: 0..10
Expression: [ ( ) ]
Formal Notation: (0, 10)

Outer Left Pulled Left

Syntax: :0..10
Expression: [ ( ) ]
Formal Notation: [0, 10)

[gafter]

I am withdrawing my championship of this issue in favor of #812