Give the TKey and TValue a name for Dictionary<TKey, TValue>

[magol]

When you use a IDictionary<TKey,TValue> you only know the type of the TKey and TValue. But if the data types are of a simple type like int och string, it can be hard to know what that data you should use.

Before it was the same problem with Tuple, but it is solved in C# 7

Below I compare Dictionary with the Tuple, both how it was before and how it is in C#7 together with my proposal.

Example (before):

var dictionary = new Dictionary<int, int>() { { 1234, 9876}  };
var tuple = new Tuple<int, int>(1234, 9876);

var keyValue = dictionary.First();
Debug.WriteLine(keyValue.Key);
Debug.WriteLine(keyValue.Value);

Debug.WriteLine(tuple.Item1);
Debug.WriteLine(tuple.Item2);

Example (proposed):

var dictionary = new Dictionary<int ItemId, int OwnerId>()  { { 1234, 9876} };
var tuple = (ItemId: 1234, OwnerId: 9876);

var keyValue = dictionary.First();
Debug.WriteLine(keyValue.ItemId);
Debug.WriteLine(keyValue.OwnerId);

Debug.WriteLine(tuple.ItemId);
Debug.WriteLine(tuple.OwnerId);

Ok, it is more common to access the data in a Dictionary by the index property (dictionary[1234]), but even then you will benefit from this. I suggest that the popup documentation reflect the name on TKey and TValue. The names is directly in the syntax line, and you don't have to read throw the maybe outdated XML documentation (if it is any).

This is only a compilation hack (like for the new Tuple) for types that are derived from IDictionary<TKey,TValue>.

[Joe4evr]

You could just write a deconstructor extension method.

public static void Deconstruct<TKey, TValue>(this KeyValuePair<TKey, TValue> kvp, out TKey key, out TValue val) 
{
    key = kvp.Key;
    val = kvp. Value;
}
//usage:
foreach (var (id, entity) in someDictionary)
{
    //.... 
}

[svick]

@Joe4evr With that, you would have to define the names at the point of deconstruction, not when declaring the dictionary. I think that's a pretty big disadvantage.

[HaloFour]

C# has no knowledge of the System.Collections.Generic.Dictionary<TKey, TValue> class. Are you suggesting that a special relationship be written into the language specification? What about other dictionary classes or other arbitrary classes that happen to be able to return data types like this? How would the compiler know that?

Or are you suggesting some deeper form of naming across generic type arguments? That's kind of already been requested at #829.

[jnm2]

@HaloFour No, this goes further even than generic type arguments, and no, no special knowledge. I want to be able to do this for fields in my own types. SO bad.

KeyValuePair is a perfect example. So is OneOf.

[bondsbw]

For a general mechanism, an attribute could be emitted to associate the generic arguments with names. Something like [GenericArgumentMemberNameAttribute("TKey", "Key"), GenericArgumentMemberNameAttribute("TValue", "Value")] on the class, or similar attributes on the properties. (Please come up with a better name. 😬)

But in this case, somehow the names would need to be pushed down from the Dictionary<int ItemId, int OwnerId> definition to set up KeyValuePair<int ItemId, int OwnerId>.

[HaloFour]

@bondsbw

How does that work where a type might expose two members of that generic type? There's simply no correlation between the generic signature of a type and its shape. Dictionary represents a very niche configuration.

[yaakov-h]

The first idea that comes to my mind is that you could add another attribute to at most one member (per generic argument) on the class.

For example:

public class KeyValuePair<TKey, TValue>
{
    [GenericArgumentMemberAlias(nameof(TKey))]
     public TKey Key;

    [GenericArgumentMemberAlias(nameof(TValue))]
    public TValue Value;
}

var kvp = new KeyValuePair<string Name, DateTime DateOfBirth>();
var name = kvp.Name; // Translated by compiler into kvp.Key
var dob = kvp.DateOfBirth; // Translated by compiler into kvp.Value

This seems like it might become unwieldy pretty quickly, though.

I can see that there's some value to be had on KeyValuePair<,> or Tuple<,> or so on... but I fail to see how Dictionary<,> could benefit from any such or similar mechanism.

[jnm2]

@yaakov-h Dictionary<TKey, TValue> is how I would add and access the KeyValuePairs, so I need a way to map Dictionary's type parameters to KeyValuePair's fields too.

I want to be able to do:

void Foo(IReadOnlyDictionary<string name, object thing> thingsByName)
{
    var x = thingsByName.Where(_ => _.name == "X")...
}

(Why not IReadOnlyCollection<KeyValuePair<string name, object thing>>? I prefer the more explicit semantics. Plus, that looks pretty ugly when that's not the semantic I want.)

[magol]

One suggestion is as following

class Foo1<T>
{
	//You can both use the name "Value" and the name given to T
	[GenericArgumentMemberName("T")]
	public T Value{get;}
}
...
var foo1 = new Foo1<int MyId>();
// Both alternaives is valid. 
foo1.Value = 1;
foo1.MyId  = 2;

And for more advanced example:

class MyKeyValue<TKey, TValue>
{
	//You can both use the name "Key" and the name given to TKey
	[GenericArgumentMemberName("TKey")]
	public TKey Key;

	//You can both use the name "Value" and the name given to TValue
	[GenericArgumentMemberName("TValue")]
	public TValue Value;
}

class Foo2<TKey, TValue>
{
	//An underlying property that does not necessarily have to have the same typing parameters.
	//The first type parameter is given the same name as TKey
	//The second type parameter is given the same name as TValue
	[GenericArgumentMemberNames("TKey",   0)]
	[GenericArgumentMemberNames("TValue", 1)]
	public MyKeyValue<string, string> Data = new MyKeyValue<string, string>();
}
...
var foo2 = new Foo2<int MyKey, int MyValue>();
foo2.Data.Key = "3";
foo2.Data.MyKey = "4";

foo2.Data.Value= "5";
foo2.Data.MyValue= "6";

[yaakov-h]

You'd then need a way to transfer the argument names between the object, and the items it returns.

i.e. an implicit understanding that Dictionary<TKey first, TValue Second>.First() is an object of type KeyValuePair<TKey first, Value second>.

That means the names have to flow from the generic types, through to the enumerator, and into and out of any LINQ methods which operate over the enumerator.

[bondsbw]

@HaloFour

How does that work where a type might expose two members of that generic type?

In my example, "Key" and "Value" are the member names to which the provided aliases would map. Any member not associated in such a way would not be impacted.

I like the example provided by @yaakov-h as well.

[CyrusNajmabadi]

One suggestion is as following

This would then not work, as Dictionary/IDictionary has no such attributes on it.

[HaloFour]

Seems like a lot of compiler chicanery for such limited use cases. You can already easily project the pairs in a dictionary via LINQ to an anonymous type or a named tuple if you really want to work with them that way.

[jnm2]

Much more value for a set of OneOf types, surely. Not to mention covering #829, and potentially the parameter-naming part of #269 which is the part I really want to see.

[ashmind]

@yaakov-h

an implicit understanding that Dictionary<TKey first, TValue Second>.First() is an object of type KeyValuePair<TKey first, Value second>

I might be wrong, but I thought it is currently understood by the compiler? The reason why it knows First() returns KeyValuePair<int, string> is exactly because TKey in KeyValuePair is the same generic parameter as the one on Dictionary.

[Thaina]

I think we should add a new TupleDictionary in https://github.com/dotnet/corefx instead

[yaakov-h]

@Thaina how would that help?

[Thaina]

@yaakov-h To use it in place of KeyValuePair Dictionary

[yaakov-h]

@Thaina mmhmm, keep going... What is it, how would it work, and how would it solve the issue in this thread using existing language features only?

[orthoxerox]

I think something like newtypes or easily constructible/deconstructible wrapper types would work much better and enable more use cases:

//newtypes
public newtype OrderID : int;
public newtype ItemID : int;

var dictionary = new Dictionary<OrderID, ItemID>() { { 1234, 9876}  };

var (orderID, itemID)= dictionary.First(); //KVP has a deconstructor
Debug.WriteLine(orderID); //orderID is of newtype OrderID
Debug.WriteLine(itemID); //itemID is of newtype ItemID

//wrappers/records
public struct OrderID(int ID);
public struct ItemID(int ID);

var dictionary = new Dictionary<OrderID, ItemID>() { { 1234, 9876}  };

var (order, item) = dictionary.First(); //KVP has a deconstructor
Debug.WriteLine(order.ID);
Debug.WriteLine(item.ID);

[NickRedwood]

Hi all. If KeyValuePair extended an interface IKeyValuePair:

interface IKeyValuePair<TKey, TValue>
{
	TKey Key { get; }
	TValue Value { get;}
}

... and IReadOnlyDictionary extended an interface IKeyedEnumerable:

interface IKeyedEnumerable<T, TKey, TValue> : IEnumerable<T> where T : IKeyValuePair<TKey, TValue>
{
	TValue this[TKey key]{ get; }
}
interface IReadOnlyDictionary<TKey, TValue> : IKeyedEnumerable<KeyValuePair<TKey, TValue>, TKey, TValue>
{
	// Rest of implementation
}

... that wouldn't break anything would it? And then anyone could make their customised IKeyValuePair with properties renamed as desired while the base interface is implemented explicitly (though I'm not sure if that's considered good C# practice or not).

struct MyKeyValuePair : IKeyValuePair<string, double>
{
	public string MyKeyName { get; }
	public double MyValueName { get; }
	string IKeyValuePair<string, double>.Key { get { return this.MyKeyName; } }
	double IKeyValuePair<string, double>.Value { get { return this.MyValueName; } }
}

... and then pass an IKeyedEnumerable (or concrete version thereof) of that around, which returns the correct MyKeyValuePair type when enumerated. Quite a lot of boilerplate but it seems to achieve the right effect.

As a side note, KeyValuePair does seem an odd item, seeing as the key -> value relation isn't actually present in the object itelf and instead relies on the containing dictionary. Regular Pair or Tuple2 seems clearer to me.

[yaakov-h]

@NickRedwood Adding an interface to IReadOnlyDictionary<,> will break any custom code that implements that interface, at least until #52 is completed.

Also, you seem to be missing a few large pieces, including getting Dictionary<,> to somehow enumerate a collection of MyKeyValuePair<,>, a type which it knows nothing about.

[NickRedwood]

@yaakov-h Ok acknowledge retrofitting an interface to IReadOnlyDictionary would break things as it stands.

Regarding your second point, all existing Dictionary implementations would still just create instances of the default IKeyValuePair i.e. KeyValuePair. A user wanting custom key-value names would need to implement IKeyedEnumerable themselves (in addition to IKeyValuePair) rather than relying on an existing Dictionary implementation.

I suppose my more general point is then, if there is (in future) some mechanism to allow retrofitting of interfaces to other existing interfaces or classes (whether it be default interface implementations, typeclasses, extension interfaces, or something else), either in Core or by the user, then those finer-grained interfaces coupled with that mechanism should (I think) allow this dictionary naming problem to be solved neatly without a new language feature. Do you agree?

[yaakov-h]

@NickRedwood

A user wanting custom key-value names would need to implement IKeyedEnumerable themselves (in addition to IKeyValuePair) rather than relying on an existing Dictionary implementation.

Having custom classes doesn't actually address this issue or any of the points in the OP.

You can already write a custom class that implements `IEnumerable<(int itemID, int ownerID)> etc. today. That's not what this issue is about.

[NickRedwood]

@yaakov-h I realise IReadOnlyDictionary is very unlikely to be changed from implementing IEnumerable<KeyValuePair<,>> to IEnumerable<T> where T : IKeyValuePair<TKey, TValue> even if it wasn't a breaking change.

You can already write a custom class that implements `IEnumerable<(int itemID, int ownerID)>

Yes, but implementing your own IReadOnlyDictionary (which is the most relevant as it's the way most code consumes dictionaries) is different - it's useless for the OP's purpose as it forces you to implement IEnumerable<KeyValuePair<,>> so you can't change the property names on your keys and values. If that was addressed somehow (which my initial suggestion would do, even if it's ugly) then that would indeed allow the OP's needs to be met with a custom implementation. But ok, mine is probably not a good solution.

(and yes I went down the wrong path talking about IKeyedEnumerable - unless the core collection interfaces change to include many finer-grained interfaces and people become used to passing around the bare minimum needed of these, the de-facto standard will be IReadOnlyDictionary).

[yaakov-h]

@NickRedwood No, the following is perfectly valid. No language changes are required:

using System;
using System.Collections;
using System.Collections.Generic;

public class CustomDictionary : IReadOnlyDictionary<string, int>, IEnumerable<(string name, int count)> {
    
    readonly Dictionary<string, int> inner;
    
    // IReadOnlyDictionary<>
    
    public bool ContainsKey(string name) => inner.ContainsKey(name);
    
    public bool TryGetValue(string name, out int count) => inner.TryGetValue(name, out count);
    
    public int this[string name] => inner[name];
    
    public int Count => inner.Count;
    
    IEnumerator<KeyValuePair<String, int>> IEnumerable<KeyValuePair<String, int>>.GetEnumerator() => inner.GetEnumerator();
    
    IEnumerator IEnumerable.GetEnumerator() => inner.GetEnumerator();
    
    public IEnumerable<string> Keys => inner.Keys;
    
    public IEnumerable<int> Values => inner.Values;
    
    // IEnumerable<()>
    
    public IEnumerator<(string name, int count)> GetEnumerator() => throw new NotImplementedException("Left as an excercise for the reader.");
}

static class Program
{
    public static void Main()
    {
        var dict = new CustomDictionary();
        
        foreach (var vt in dict)
        {
            Console.WriteLine($"{vt.name}: {vt.count}");
        }
    }
}

[NickRedwood]

The custom naming doesn't survive being passed as IReadOnlyDictionary though, and I assumed that retaining the naming while being passed around as a Core interface would be a requirement of any solution.

[Jorenkv]

Tuple names also disappear when putting a named tuple like (string name, int age) into a variable of type (string, int). The programmer understands that when they convert Dictionary<string name, int age> to IReadOnlyDictionary<string, int> they lose the names, and that if they want them to be preserved they should use IReadOnlyDictionary<string name, int age> instead.

Basically the proposal is to allow consumers of generic types to give names to generic type arguments just like they are allowed for tuple types, and for implementors of generic types to support this feature by passing on these names as aliases for properties (perhaps even other members?) and passing on these names to generic type constructions it itself consumes (like Dictionary<> would do to its KeyValuePair<> instantiations). These names are erased as usual, have no impact on semantics except where used directly in the source code.

[TobiasKnauss]

Hello all,
I know that this discussion has not seen much activity in the last years. However, named keys and values is something that I and my colleagues would like to see as well.
This would make work with dictionaries much easier in many cases: Sometimes we even use named-tuple-lists where a dictionary would be more appropriated, just because of the custom item names that we can define.

[ufcpp]

See also: #1883 #5321

[FaustVX]

I just thought about that, but could that be resolved by the role proposal #5497 ?