Proposal: Supporting C# 7 deconstruction of certain types.

[jamesqo]

Background

C# 7 added support for deconstruction of user-defined types via a Deconstruct(out ...) method. (see it in action) It would make sense to be able to use this feature with tuple-like types such as KeyValuePair and DictionaryEntry.

Proposal

public struct KeyValuePair<TKey, TValue>
{
    // BLOCKED (do not add now): [EditorBrowsable(EditorBrowsableState.Never)]
    public void Deconstruct(out TKey key, out TValue value);
}

public struct DictionaryEntry
{
    // BLOCKED (do not add now): [EditorBrowsable(EditorBrowsableState.Never)]
    public void Deconstruct(out object key, out object value);
}

Usage

public void MyDictionaryMethod()
{
    var dict = new Dictionary<int, string>();
    dict.Add(1, "2");
    var (one, two) = dict.First();
}

[justinvp]

KeyValuePair<TKey, TValue>? DictionaryEntry? Any others?

[stephentoub]

@MadsTorgersen, what is the thinking about what types should expose deconstructors?

Personally, I think it makes sense for tuple-like types, e.g. KeyValuePair, DictionaryEntry, Tuple, ValueTuple, etc. I'm less convinced it's a good idea for other types just as a way to extract their fields.

[MadsTorgersen]

I agree completely. No reason to reinvent the dot.

[mellinoe]

The fixed-size types in System.Numerics.Vectors could be a decent candidate for this too: Vector2, Vector3, Vector4, Plane, Quaternion, Matrix3x2 (?), Matrix4x4 (?).

[jamesqo]

@stephentoub @MadsTorgersen I didn't think this would be a controversial proposal; I thought this was basically how deconstruction was intended to be used. However, if you disagree, I'll update the proposal to include just KeyValuePair/DictionaryEntry.

[JonHanna]

Of the types mentioned here, I'm not convinced about ArraySegment (but maybe I just don't use it enough), but with the drawing primitives I think it's common enough to want to get all instance properties in a use that it would make sense.

[jamesqo]

@JonHanna, just updated the proposal; see @stephentoub & @MadsTorgersen's comments.

[JonHanna]

Yep. I'm speaking in favour of that part of the original. I think tough there are going to be a bunch of debates in the near future in a bunch of .NET projects where one side thinks of a type as tuple-y and the other doesn't. (I'll admit to abusing Point to give me a quick integer 2-tuple in the days of .NET 1.1, so maybe that's colouring my thinking).

[jamesqo]

@karelz, maybe this is OK for review? I edited the original proposal and changed it to only include @justinvp's suggestions, namely KeyValuePair and DictionaryEntry. I think those types are pretty much intended to be used with this language feature.

[terrajobst]

@MadsTorgersen, @KrzysztofCwalina asked whether exposing a casting operator from TypeX to Tuple/ValueTuple would work, too. Does it have to be a Descontruct method?

I assume converting from a KeyValuePair<,> to ValueTuple<,> would work with an implicit conversion, while decontructing into multiple locals would not. Is that understanding correct?

[jamesqo]

@MadsTorgersen @terrajobst I just had an idea-- should we do this for Nullable as well? Usage:

(bool hasValue, T valueOrDefault) = nullable;

I think F# already allows you to do this for out-parameters.

[MadsTorgersen]

@jamesqo How would you use this? I fear that any real usage would get awkward, because you want to test the Boolean, but to do that you first have to extract it into a local.

It seems to me that nullables are better consumed with patterns or the ?? operator. Ideally they would have a TryGetValue method, which could be easily consumed with out variables.

[karelz]

@MadsTorgersen @KrzysztofCwalina can you please check @terrajobst's question above (https://github.com/dotnet/corefx/issues/13746#issuecomment-262335120)?