MultiValueDictionary

[roederja]

Is there a chance to include the MultiValueDictionary class from the old Microsoft.Experimental.Collections package in dotNext: https://devblogs.microsoft.com/dotnet/multidictionary-becomes-multivaluedictionary/

Or is there a reason to keep it out? I personally found it very useful in production code and safes you from writing boilerplate code for Dictionaries where the value is a list or set.

[sakno]

It looks like a corner case for dictionary. MultiValueDictionary can be represented by Dictionary<TKey, List<TValue>>. It was implemented by Microsoft.Experimental.Collections in the same way. So I see no reason to introduce a new class, but it is possible to convert some boilerplate code to something reusable using extension methods, e.g.

public static IReadOnlyCollection<TValue> TryGetValues<TKey, TValue, TCollection>(this IDictionary<TKey, TCollection> dictionary)
  where TKey : notnull
  where TCollection : class, IReadOnlyCollection<TValue>;

Is it reasonable for you? If yes, you can provide a set methods you want to see in the library as a proposal.

[sakno]

Also, I found some ambiguity with API surface. For instance,

bool TryAdd(TKey key, TValue value);

What this method should do? Don't add a value to the list if key is already exist (just like regular Dictionary) or try to add the value to the list/set and return false if value is already exist.

[roederja]

The MultiValueDictionary from Microsoft doesn't have TryAdd - probably for that reason.

[sakno]

But what if dictionary created with an option to use HashSet as a storage for values?

[roederja]

It will always call Add on the underlying collection. In the list case you’d end up with duplicates - in the set case you won’t. Seems reasonable to me.

[sakno]

This is why List<T>.Add doesn't return anything while HashSet<T>.Add returns bool. It's good to know about duplicate value, however, in the context of MultiValueDictionary such a method produces ambiguity.