[Proposal] String literals denoting matching substrings in list pattern

[Rekkonnect]

Summary

An enhanced way to denote substrings when matching a string using list patterns.

Motivation

Currently, using list patterns against strings for capturing a simple variable within a specific region is inconvenient, as you would have to specify each character individually. Take for example matching field names denoting backing fields for specific properties (they are in the form <PropertyName>k__BackingField). The only available syntax currently is this:

name is ['<', .. string propertyName, '>', 'k', '_', '_', 'B', 'a', 'c', 'k', 'i', 'n', 'g', 'F', 'i', 'e', 'l', 'd']

Specifying each character individually defeats the purpose of using list patterns altogether, a better approach would be to use a combination of StartsWith and EndsWith, and defining a generic intermediate string capturing method like so.

Design

Strings are very well-known types, and string literals have special casing in many a cases. In this one, a proposed way is to allow raw string literals inside a list pattern involving IEnumerable<char> types, including a string. With the above example in mind, the following should be legal:

public static bool IsBackingFieldName(string name)
{
    return name is ['<', .. string propertyName, ">k__BackingField"];
}

This would mean that name starts with '<' and ends with ">k__BackingField", while also capturing the value in between the two affixes, into the variable propertyName. String literals inside a list pattern over char values would be handled with that in mind.

Bonus

With the above use case in mind, and with the fact that most list patterns over char sequences are for this purpose, we could utilize the StartsWith and EndsWith methods that are present on the underlying type, if it's a string or a [ReadOnly]Span<char>. In other words, the above example would exactly be lowered into (code adjusted from the SharpLab example linked above):

public static bool IsBackingFieldName(string name)
{
    bool matches = name.StartsWith('<') && name.EndsWith(">k__BackingField");
    string propertyName = null;
    if (matches)
    {
        int offset = 1;
        int length = name.Length - 1 - ">k__BackingField".Length;
        int endIndex = offset + length;
        propertyName = name[offset..endIndex];
    }
                       
   return matches;
}

Alternatives

As demonstrated already:

• Usage of StartsWith, EndsWith, Substring by hand with some arithmetic operations on the indexes.
• Writing down each individual character in the list pattern as already available today.

Credits

@just-ero for the example and the problem at hand

[jnm2]

Yes please, I've been running into this since near the beginning of using list patterns. We should consider u8 strings too.

Syntax that came to mind first was additional constant spreads, rather than listing the string as an element of the list pattern:
['<', .. var propertyName, .. ">k__BackingField"]

This would clear the way for constants to be used:
[.. ConstPrefix, .. var contents, .. ConstSuffix]

[Rekkonnect]

Nice observation about the usage of constants too. I wanted to avoid the usage of the spread operator in order to not confuse it with the actual spreads that are captured, however it seems that with constants we would run into conflicts as they could also represent types. I'd like to hear your thoughts on why you'd prefer the presence of the spread operator over its absence in this feature.

[jnm2]

Besides specifically wanting to use constants, it also feels more logical to me to bridge the two worlds using a spread. In [.. const1, .. var middle, .. const2], you can see structurally that 'const1' and 'middle' are the same kinds of things: collections of elements, not directly elements themselves of the list being matched.

It also feels at first blush more safe for future generalizations beyond a special char/string or byte/u8 relationship.

On the other hand, it is interesting that "a" and 'a' would mean the same thing, so the element of confusion would not be there.

[jnm2]

Imagine a future generalization that would enable the following progression.
Initially, you want to match any two characters:

[.. { Count: 2 }, .. var rest]

Now, you realize you want to match two specific characters:

[.. "xy", .. var rest]

Removing the .. at that point seems like a strange thing to do.

(This generalization is exploring the logical consequences of choices made about whether .. is used, but not assuming that we will or should actually implement this specific capability.)

[jnm2]

I also want to mention the equivalence I see between ['a', 'b', 'c'] and "abc". As patterns on strings, these mean the same thing. There's even interest in letting collection expressions allow both forms to be the same string constant.

In collection expressions and also potentially (at least logically) in patterns, [.. ['a, 'b', 'c'], would indicate something different from [['a', 'b', 'c'],.
Therefore I'd expect [.. "abc", and ["abc" to respectively correspond to each of those distinct meanings.