A comprehensive list of pattern-based language features?

[tuespetre]

I am fascinated with the way some language features are interface-based whereas others are simply pattern-based.

Here is the list I have so far:

• Main (thanks @jnm2 and @yaakov-h)
• foreach iterators
• query expressions
• awaitable expressions (task types)
• deconstruction (thanks @yaakov-h and @zippec)
• fixed statements (thanks @jnm2)
• async methods (builder types) (thanks @jnm2)
• collection initializers (thanks @ufcpp)
• using (very new/recent) (thanks @jnm2)

Are there any more than this, and is there some kind of unambiguous term that can be used to refer to this type of construct as a whole (something that 'Googles better than' the term 'c# language pattern'?) Would it be useful in general if there were a section in the spec devoted to listing such constructs (even the interface-based ones) and discussing the merits of pattern-versus-interface-based language constructs?

[yaakov-h]

Deconstruction is another.

[jveselka]

@tuespetre Tuple deconstruction is also pattern-based

[HaloFour]

Depending on what you consider a "pattern" you could probably include tuples and extension methods.

Tuples require that the container type have the name System.ValueTuple<...> with a specific shape, specifically a constructor accepting the elements and those elements as public fields. But it doesn't care where the type lies or how it's implemented beyond those requirements.

Extension methods require that an attribute System.Runtime.CompilerServices.ExtensionAttribute exists, but it doesn't care where it lives. You can enable extension methods even when targeting earlier versions of the framework by providing your own implementation of that attribute class.

[jnm2]

This is in C# 7.3: https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.3/pattern-based-fixed.md

I am fascinated with the way some language features are interface-based whereas others are simply pattern-based.

I think IDisposable is the odd one out, and there's a proposal on fixing that: #93

@HaloFour

Not to mention FormattableString, ReadOnlyAttribute, ParamsAttribute, and such, and possibly caller info attributes.

[jnm2]

Also, separate from await (consumer side) which is exactly as it was in C# 5, async (producer side) showed up in C# 7 with custom builders: https://github.com/dotnet/roslyn/blob/master/docs/features/task-types.md

[ufcpp]

Collection initializers.
(requires IEnumerable<T> but, the Add method is pattern-based.)

[jnm2]

@ufcpp Are collection index initializers also pattern-based?

[ufcpp]

Umm..., indexer initializers can be used on any types which have an indexer.

class Program
{
    static void Main()
    {
        var x = new X { [0] = 1, [1] = 2, [2] = 3, };
        var y = new Y { [0] = 1, [1] = 2, [2] = 3, };
    }
}

class X
{
    public int this[int index] { get => 0; set { } }
}

class Y
{
    int _dummy;
    public ref int this[int index] { get => ref _dummy; }
}

but if you regard this as pattern-based, object initializers are also pattern-based?

[jnm2]

True, never mind.

[tuespetre]

Thanks for the help everyone! 😄 Great stuff.

@HaloFour I don't think I would consider ValueTuple and friends as being 'pattern-based', mostly because that is not much different to me than int and friends.

@jnm2 ReadOnlyAttribute as in the System.ComponentModel one? Where is that used? FormattableString and ParamsAttribute are interesting to think about, just as @HaloFour mentioned the ExtensionAttribute, and there is also the ValueTupleNamesAttribute. I see those as falling into a different category, though. Dispose by convention would be a neat addition (that's something I always wondered about too) and I hope we get the with pattern sooner rather than later.

I suppose the best way I can think of to put it now is I am considering 'pattern-based' constructs to be those where the language construct is looking at some type and attempting to resolve some instance or extension member according to a naming/signature convention.

[jnm2]

@tuespetre

ReadOnlyAttribute as in the System.ComponentModel one?

No, the C# 7.2 features readonly ref and readonly struct. Roslyn actually declares these attribute classes in your code if you aren't referencing a BCL which contains them.

See also #935 (I need to update and format the list).

I see those as falling into a different category, though.

Yes. Quite fair to keep that separate.

deconstruction (no section in the spec in this repo to link to yet)

Our best guess is that the team will not have time to update the spec from the C# 6 draft for the quite a while. I would suggest the link https://github.com/dotnet/roslyn/blob/master/docs/features/deconstruction.md which the C# version history uses.

[jnm2]

I see those as falling into a different category, though.

Along with FormattableString, Monitor is a fixed named type with the compiler recognizes and associates to the lock syntax. Still a different category since the exact type name is hardcoded and there can be only one.

Does class X { static (int|void) Main( (string[] x)? ) { } } count as pattern-based feature? The entry point when automatically determined by the compiler is defined in the language spec, right?

[yaakov-h]

( int | void | Task<int> | Task ) 😉

[tuespetre]

I think that is entirely fair to call 'pattern-based'.

One of the most basic and important ones and we recognize it last, huh? 😄

[jnm2]

Does it count that the syntax [Foo] resolves to a type named FooAttribute?

[Joe4evr]

Does it count that the syntax [Foo] resolves to a type named FooAttribute?

Maybe, but while suffixing attribute types with Attribute is the common convention (and everyone should definitely apply it), it's not strictly speaking required. If the type simply is Foo : Attribute (or it indirectly inherits Attribute), it'd work just the same.

[jnm2]

@Joe4evr I'm familiar with that. The Attribute-eliding behavior that I referred to might still count as a pattern, depending on what @tuespetre is looking for.

[jnm2]

@tuespetre Will using make the grade when #1703 is merged, or when C# 8 ships?

[tuespetre]

@jnm2 If #1623 does make it into C# 8, using will reach the bar for me.

[jnm2]

@tuespetre It's time :)