Hacker News Reader

Comment by nycdotnet | Hacker News Reader

Agreed that `var` isn't going anywhere, but this feature's best use case is with complex generics/enumerables and things like anonymous tuple types. For example:

  // old:
  var x = new List<KeyValuePair<string, int>>
  {
    new KeyValuePair<string, int>("a", 1),
    new KeyValuePair<string, int>("b", 2)
  };

  // new
  var x = new List<KeyValuePair<string, int>>
  {
    new("a", 1),
    new("b", 2)
  };

View on HN

Another option if you're still on .NET framework is to use a collection initializer extension method. I add a comment when I do this and place the extension method in a separate namespace.

    // ListExtensions.cs
    internal static class
    ListExtensions
    {
        public static void Add(this List<KeyValuePair<string, int>> list, string key, int value)
        {
            list.Add(new KeyValuePair<string, int>(key, value));
        }
    }
    
    // new w/extension method
    var x = new List<KeyValuePair<string, int>>
    {
        {"a", 1},
        {"b", 2},
    };

Wow, when I (only a C# dabbler) read about this feature in the article I thought it sounded incredibly silly, but this really sells it. Was there really no better way to create tuples before?

You could create tuples with `Tuple.Create("a", 1)` since at least .NET 4, if not 3.

Since C# 7 you can also create tuples using just `("a", 1)`. But tuples are not KeyValuePairs. So the new "new" syntax will be very helpful in a lot of cases.

I really don't understand why they haven't added implicit conversion operators between the modern ValueTuple and the legacy value-types like KeyValuePair, Tuple, and Pair, grumble. It's a non-breaking change!

Adding that is potentially a source breaking change. Admittedly an easy enough one to address, and they are more willing to make such changes in CoreFx, then they historically were, so it is not impossible that they could decide to do it.

For an example of this being a breaking change. Let's say that B is some other type implicitly convertable to A.

The following two method overloads exists:

    void Method(A a, ValueTuple<int,int> vt);
    void Method(B b, Tuple<int, int> t);

Right now `Method(SomeB, (4,5))` compiles fine, but if your proposed conversions were added, it would suddenly yield `CS0121: The call is ambiguous between the following methods or properties:...`.

Tuple is not a value type. And this means that they won't add an implicit conversion, because right now a major focus of .NET and C# is also performance. and this conversion would mean an implicit heap allocation. They'd rather avoid adding features of this sort as I understand it.

C# (as of 7.0) has pretty nice tuple syntax that supports all things you expect (deconstruction, etc):

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

But the situation here is that the type KeyValuePair is older than that and isn't a tuple.

> Was there really no better way to create tuples before?

Here are some other options for code like the grandparent post. I tend to either live with the boilerplate or use a local function.

1. Use a collection initializer extension method (https://news.ycombinator.com/item?id=26641997).

2. Define a local helper function.

    KeyValuePair<string, int> KeyValue(string key, int value)
    {
        return new KeyValuePair<string, int>(key, value);
    }

    // new w/local function
    var x = new List<KeyValuePair<string, int>>
    {
        KeyValue("a", 1),
        KeyValue("b", 2)
    };

3. Use an array of C# 7 tuples and convert them in a loop or query.

4. Use generics to infer the argument types à la Tuple.Create. This technique can be helpful for using anonymous types with collections.

    //KeyValuePair.cs
    internal static class KeyValuePair
    {
        public static KeyValuePair<TKey, TValue> Create<TKey, TValue>(TKey key, TValue value)
        {
            return new KeyValuePair<TKey, TValue>(key, value);
        }
    }


    // new w/helper class
    var x = new List<KeyValuePair<string, int>>
    {
        KeyValuePair.Create("a", 1),
        KeyValuePair.Create("b", 2)
    };

Reply on news.ycombinator.com