Add a Deconstruct method for syntax nodes

[RikkiGibson]

This made me realize a void Deconstruct(this SyntaxNode, out SyntaxKind) might be actually useful. Currently matching multi-kind nodes is kind of ugly..

is RecordDeclarationSyntax(SyntaxKind.RecordStructDeclaration) { ParameterList: not null }

Originally posted by @alrz in #52702 (comment)

---

I recall often being stymied by the inability to match the SyntaxKind when pattern matching against a syntax node. It might work nicely to introduce an internal extension which lets us deconstruct the SyntaxKind.

[CyrusNajmabadi]

Well, you can write this:

RecordDeclarationSyntax { RawKind: (int)SyntaxKind.RecordStructDeclaration, ParameterList: not null }

The drawback is that RawKind is typed as an int. We could have a CSharpKind property on the type that then exposes that as SyntaxKind which would make thigns nicer. It's totally unclear to me why we made Kind an extension method...

[RikkiGibson]

It's totally unclear to me why we made Kind an extension method...

According to 93e9eaf#r11017500 back in 2015,

Consistency with extension methods of the same name.

[CyrusNajmabadi]

Seems like it should have been a property. But alas here, we are. Maybe we might make it possible for pattern matching to support something like { Kind(): .RecordStructDeclaration } in the future.

[alrz]

RawKind

That's not that bad. But I'd still prefer Deconstruct cause it perfectly frame the type check part of the match. just my 2c.

Maybe we might make it possible for pattern matching to support something like { Kind(): .RecordStructDeclaration } in the future.

I think extension props is more likely than methods in patterns though.

[RikkiGibson]

I have been thinking off and on about the ergonomics of this pattern, particularly about the fact that these forms would work:

if (node is (SyntaxKind kind) { }) { ... }
if (node is SyntaxNode(SyntaxKind kind)) { ... }
if (node is (SyntaxKind kind) _) { ... }

But this would not:

if (node is (SyntaxKind kind)) { ... }

I don't know if this is particularly solvable or not. But it feels "weird", similar to how before we had type patterns users had to do e.g. node switch { SyntaxNode _ => ... } instead of just node switch { SyntaxNode => ... }.

[alrz]

I don't think that matters, we probably wouldn't want to do any of those?

See some sample usages in #53553 (https://github.com/dotnet/roslyn/.../UseRecursivePatternsCodeRefactoringProvider.cs)
Also #53663

[RikkiGibson]

It looks like this is already present in Workspaces/SharedUtilitiesAndExtensions, so this issue tracks making the API available in the compiler layer.

roslyn/src/Workspaces/SharedUtilitiesAndExtensions/Compiler/CSharp/Extensions/SyntaxNodeExtensions.cs

Lines 24 to 27 in e43614f

	public static void Deconstruct(this SyntaxNode node, out SyntaxKind kind)
	{
	kind = node.Kind();
	}