Proposal: Nominal deconstruction

[YairHalberstadt]

One very nice feature of recursive patterns is their ability to deconstruct objects into the relevant properties: For example:

public static class Utils {
    public static string PrettyPrint(TextRange? textRange) {
        
        if (textRange is {
            Start: { Line: var startLine, Column: var startColumn },
            End: { Line: var endLine, Column: var endColumn },
        })
        {
            return $"Start: [{startLine}:{startColumn}], End: [{endLine}:{endColumn}]";
        }
        else
        {
            return "";
        }
    }
}

public struct TextRange
{
	public TextRange(TextPoint start, TextPoint end)
	{
		Start = start;
		End = end;
	}

	public TextPoint Start { get; }
	public TextPoint End { get; }
}

public struct TextPoint
{
	public TextPoint(int line, int column)
	{
		Line = line;
		Column = column;
	}

	public int Line { get; }
	public int Column { get; }
}

I find this much nicer than deconstructing manually:

var startLine = textRange.Start.Line;
var startColumn = textRange.Start.Column;
var endLine = textRange.End.Line;
var endColumn = textRange.End.Column;

However this only works when you do a pattern match. In this case textRange can be null so a pattern match is necessary, so this works well.

What if textRange wasn't null? You'd have to keep the pattern match and the condition in order to enable this deconstruction, even though the condition is guaranteed to succeed. This is not very good style.

An alternative is to do this:

_ = textRange is {
            Start: { Line: var startLine, Column: var startColumn },
            End: { Line: var endLine, Column: var endColumn },
        };

This is a little bit of a hack, and only works because TextRange is a struct, so cannot be null, so the variables are definitely assigned. What if TextRange was a class:

#nullable enable
    public static string PrettyPrint(TextRange textRange) {
        Debug.Assert(textRange is not null);
        
        _ = textRange is {
            Start: { Line: var startLine, Column: var startColumn },
            End: { Line: var endLine, Column: var endColumn },
        };

        return $"Start: [{startLine}:{startColumn}], End: [{endLine}:{endColumn}]"; //definite assignment error
    }

It would be useful to have a way to explicitly deconstruct something without doing pattern matching.

This can be considered Nominal Deconstruction as a counterpart to the existing Positional Deconstruction. This fits in with the parallel between Positional Records which can be positionally deconstructed, and Nominal Records which must be nominally deconstructed.

Example

public static class Utils {
    public static string PrettyPrint(TextRange? textRange) {
        Debug.Assert(textRange is not null);
        
        var {
            Start: { Line: startLine, Column: startColumn },
            End: { Line: endLine, Column: endColumn },
        } = textRange;

        return $"Start: [{startLine}:{startColumn}], End: [{endLine}:{endColumn}]";
    }
}

public classTextRange
{
	public TextRange(TextPoint start, TextPoint end)
	{
		Start = start;
		End = end;
	}

	public TextPoint Start { get; }
	public TextPoint End { get; }
}

public class TextPoint
{
	public TextPoint(int line, int column)
	{
		Line = line;
		Column = column;
	}

	public int Line { get; }
	public int Column { get; }
}

Syntax

nominal_deconstruction_statement:
    var? nominal_deconstruction = expression ;
    ;

nominal_deconstruction:
     { nominal_deconstruction_part (, nominal_deconstruction_part)* ,? }
     ;

nominal_deconstruction_part:
     identifier: (nominal_deconstruction? | (var | type)? identifier)
    ;

Semantics

A nominal deconstruction is equivalent to:

if (!(expression is nominal_deconstruction))
    throw new NullReferenceException();

Except for:

1. a nominal deconstruction can assign to existing variables, instead of just declaring new ones
2. one can put var before a nominal_deconstruction, in which case all of the nominal_deconstruction_parts are declarations rather than assignments, and cannot declare their type.

Open questions:

Should you be able to assign the deconstructed object to a variable at the same time:

e.g.

        var {
            Start: { Line: startLine, Column: startColumn } start,
            End: { Line: endLine, Column: endColumn } end,
        } textRange = CalculateTextRange();

[Richiban]

It's probably worth pointing out that since Javascript introduced the ability to deconstruct like that it became incredibly popular, to the point that some devs seem to rarely use dot-syntax for properties. Here's some code from one of our repos committed not too long ago, and this pattern is present everywhere:

  render() {
    const {
      product: {
        id,
        name,
        url,
        sizes,
        boutiqueUrl,
        imageId,
        boutiqueName,
        currentPrice,
        previousPrice,
        freeUkShipping
      },
      currency,
      wrapperClass,
      analyticsValuesForPDP,
      onProductClick,
      loading
    }: Props = this.props;

    //...
}

FWIW It could be that Javascript's dynamic nature is what makes this considered best practice; i.e. the properties that are actually used are all declared up front in the method.

[YairHalberstadt]

@Richiban So does javascript use the same identifier name for the property and the local?

I think that wouldn't work to well in C#, especially as the naming conventions are different. However the compactness is very nice.

[Richiban]

So does javascript use the same identifier name for the property and the local?

You get that by default (the local gets the same name as the property if you don't override the name) at the site of deconstruction. In other words:

const { x, y } = data;

is the same as:

const { x: x, y: y } = data;

It's identical to C#'s syntax for prop deconstruction in pattern matching, except that C# requires the var keyword:

Typescript

const { x: localX, y: localY } = data;

vs (theoretical syntax) C#:

var { X: var localX, Y: var localY } = data;

[333fred]

Relevant: #3107

[leandromoh]

just complementing:

The advantage of this feature over Deconstruct methods is that this is a lot more flexible.

• reuse the well know pattern matching syntaxe to deconstruct, which might be more intuitive than create extension methods for an existing type
• users does not need to reason about members position on deconstruct
• no need to define any deconstruct method (which might become a lot of boilerplate code since we would need one method for each tuple deconstruct cardinality)
• avoid ambiguity (when there is more than one deconstruct method with same quantity of parameters compiler show compilation error)