156

Title is basic enough, why can't I:

Dictionary<string, string> dic = new Dictionary<string, string>();
dic.AddRange(MethodThatReturnAnotherDic());
Custodio
  • 8,594
  • 15
  • 80
  • 115
  • 2
    There are a lot that don't have AddRange, which has always mystified me. Like Collection<>. Just always seemed odd that List<> had it, but not Collection<> or other IList and ICollection objects. – Tim May 18 '11 at 20:30
  • 50
    I'm going to pull an Eric Lippert here: "because no one ever designed, specified, implemented, tested, documented and shipped that feature." – Gabe Moothart May 18 '11 at 20:36
  • 5
    @ Gabe Moothart - that's exactly what I had assumed. I love using that line on other people. They hate it though. :) – Tim May 18 '11 at 20:41
  • See: http://stackoverflow.com/questions/294138/merging-dictionaries-in-c – tbridge May 18 '11 at 20:29
  • 2
    @GabeMoothart wouldn't it be simpler to say "Because you can't" or "Because it doesn't" or even "Because."? - I'm guessing that's not as fun to say or something? --- My follow up question to your (I'm guessing quoted or paraphrased) response is "Why didn't anyone ever design, specify, implement, test, document and ship that feature?", to which you might very well be forced to respond with "Because no one did", which is on par with the responses I suggested earlier. The only other option I can envision is not sarcastic and is what the OP was actually wondering. – Code Jockey Oct 22 '14 at 18:15
  • @CodeJockey The reason is hardly ever "Because you can't". For example, using an Enum as a generic constraint. The answer was always Eric Lippert's. Jon Skeet saw that there was absolutely nothing in the spec that prohibited it, and [created his own library written in IL to give that ability](https://codeblog.jonskeet.uk/2009/09/10/generic-constraints-for-enums-and-delegates/) 10 years ago. Now, they have finally gotten around to "designing, specifying, implementing, testing, documenting, and shipping" the feature in C# 7.3. – krillgar Jan 17 '19 at 11:05
  • 1
    You can, indirectly: `MethodThatReturnAnotherDic().ToList.ForEach(kvp => dic.Add(kvp.Key, kvp.Value));` As others have mentioned, you might want to be careful with duplicates. – Ama Mar 24 '20 at 13:27

13 Answers13

96

A comment to the original question sums this up pretty well:

because no one ever designed, specified, implemented, tested, documented and shipped that feature. - @Gabe Moothart

As to why? Well, likely because the behavior of merging dictionaries can't be reasoned about in a manner that fits with the Framework guidelines.

AddRange doesn't exist because a range doesn't have any meaning to an associative container, as the range of data allows for duplicate entries. E.g if you had an IEnumerable<KeyValuePair<K,T>> that collection does not guard against duplicate entries.

The behavior of adding a collection of key-value pairs, or even merging two dictionaries is straight-forward. The behavior of how to deal with multiple duplicate entries, however, is not.

What should be the behavior of the method when it deals with a duplicate?

There are at least three solutions I can think of:

  1. throw an exception for the first entry that is a duplicate
  2. throw an exception that contains all the duplicate entries
  3. Ignore duplicates

When an exception is thrown, what should be the state of the original dictionary?

Add is almost always implemented as an atomic operation: it succeeds and updates the state of the collection, or it fails, and the state of the collection is left unchanged. As AddRange can fail due to duplicate errors, the way to keep its behavior consistent with Add would be to also make it atomic by throwing an exception on any duplicate, and leave the state of the original dictionary as unchanged.

As an API consumer, it would be tedious to have to iteratively remove duplicate elements, which implies that the AddRange should throw a single exception that contains all the duplicate values.

The choice then boils down to:

  1. Throw an exception with all duplicates, leaving the original dictionary alone.
  2. Ignore duplicates and proceed.

There are arguments for supporting both use cases. To do that, do you add a IgnoreDuplicates flag to the signature?

The IgnoreDuplicates flag (when set to true) would also provide a significant speed up, as the underlying implementation would bypass the code for duplicate checking.

So now, you have a flag that allows the AddRange to support both cases, but has an undocumented side effect (which is something that the Framework designers worked really hard to avoid).

Summary

As there is no clear, consistent and expected behavior when it comes to dealing with duplicates, it's easier to not deal with them all together, and not provide the method to begin with.

If you find yourself continually having to merge dictionaries, you can of course write your own extension method to merge dictionaries, which will behave in a manner that works for your application(s).

Alan
  • 45,915
  • 17
  • 113
  • 134
  • 57
    Totally false, a dictionary should have an AddRange(IEnumerable> Values) – Gusman Mar 05 '15 at 15:54
  • 1
    @Gusman The concept of "Range" does not fit for a Dictionary. What is a range of data wrt an associative container? Where does it get added? In List types, the data is added to the end. For associative containers there is no concept of end. Instead the data would be merged. What happens if your IEnumerable contains duplicate KVPs? – Alan Jun 18 '15 at 21:06
  • 1
    In a dictionary, when you add an element it's added to the end of the internal list. It internally has a list of KeyValuePair as you can check doing a foreach to the dictionary. Also, if you check the definition of "range" it says: "A number or grouping of things in the same category or within specified limits", so, a group (via a list, array or IEnumerable) of KeyValuePair items is indeed a range to a dictionary. But, anyway, if you prefer to think about it with other name, then call it "AddItems", which should expect an IEnumerable> and then add all the items. – Gusman Jun 19 '15 at 13:18
  • 35
    If it can have Add, it should also be able to have add multiple. The behavior when you try to add items with duplicate keys should be the same as when you add a single duplicate keys. – Uriah Blatherwick Jul 08 '15 at 19:29
  • 6
    `AddMultiple` is different than `AddRange`, regardless it's implementation is going to be wonky: Do you throw an exception with an array of *all* the duplicate keys? Or do you throw an exception on the first duplicate key you encounter? What should be the state of the dictionary if an exception is thrown? Pristine, or all the keys that succeeded? – Alan Jul 09 '15 at 01:11
  • 3
    Okay, so now I have to manually iterate my enumerable and add them individually, with all of the caveats about duplicates you mentioned. How does omitting it from the framework solve anything? – doug65536 Oct 08 '16 at 21:19
  • 7
    @doug65536 Because you, as the API consumer, can now decide what you want to do with each individual `Add` -- either wrap each `Add` in a `try...catch` and catch the duplicates that way; or use the indexer and overwrite the first value with the later value; or preemptively check using `ContainsKey` before attempting to `Add`, thus preserving the original value. If the framework had an `AddRange` or `AddMultiple` method, the only simple way to communicate what had happened would be via an exception, and the handling and recovery involved would be no less complicated. – Zev Spitz Jan 19 '17 at 21:38
  • 1
    That's why god invented overloads. The discussion and notes provided by Alan are well thought out and I learnt quite a bit from reading his comments. It's complicated, and imho some best practices should be provided via a set of overloads to deal nice and cleanly with the different scenarios discussed, therefore I agree with @Gabe it's probably just because it wasnt done, not because it shouldnt. – snowcode May 20 '18 at 17:52
  • @Gusman "In a dictionary, when you add an element it's added to the end of the internal list" This is false - the dictionary finds the appropriate "slot" to store the item in so it can use an O(1) hash-code lookup. – D Stanley Apr 09 '21 at 00:51
59

I've got some solution:

Dictionary<string, string> mainDic = new Dictionary<string, string>() { 
    { "Key1", "Value1" },
    { "Key2", "Value2.1" },
};
Dictionary<string, string> additionalDic= new Dictionary<string, string>() { 
    { "Key2", "Value2.2" },
    { "Key3", "Value3" },
};
mainDic.AddRangeOverride(additionalDic); // Overrides all existing keys
// or
mainDic.AddRangeNewOnly(additionalDic); // Adds new keys only
// or
mainDic.AddRange(additionalDic); // Throws an error if keys already exist
// or
if (!mainDic.ContainsKeys(additionalDic.Keys)) // Checks if keys don't exist
{
    mainDic.AddRange(additionalDic);
}

...

namespace MyProject.Helper
{
  public static class CollectionHelper
  {
    public static void AddRangeOverride<TKey, TValue>(this IDictionary<TKey, TValue> dic, IDictionary<TKey, TValue> dicToAdd)
    {
        dicToAdd.ForEach(x => dic[x.Key] = x.Value);
    }

    public static void AddRangeNewOnly<TKey, TValue>(this IDictionary<TKey, TValue> dic, IDictionary<TKey, TValue> dicToAdd)
    {
        dicToAdd.ForEach(x => { if (!dic.ContainsKey(x.Key)) dic.Add(x.Key, x.Value); });
    }

    public static void AddRange<TKey, TValue>(this IDictionary<TKey, TValue> dic, IDictionary<TKey, TValue> dicToAdd)
    {
        dicToAdd.ForEach(x => dic.Add(x.Key, x.Value));
    }

    public static bool ContainsKeys<TKey, TValue>(this IDictionary<TKey, TValue> dic, IEnumerable<TKey> keys)
    {
        bool result = false;
        keys.ForEachOrBreak((x) => { result = dic.ContainsKey(x); return result; });
        return result;
    }

    public static void ForEach<T>(this IEnumerable<T> source, Action<T> action)
    {
        foreach (var item in source)
            action(item);
    }

    public static void ForEachOrBreak<T>(this IEnumerable<T> source, Func<T, bool> func)
    {
        foreach (var item in source)
        {
            bool result = func(item);
            if (result) break;
        }
    }
  }
}

Have fun.

ADM-IT
  • 3,719
  • 1
  • 25
  • 26
  • You don't need `ToList()`, a dictionary is an `IEnumerable`. Also, the second and third method methods will throw if you add an existing key value. *Not* a good idea, were you looking for `TryAdd`? Finally, the second can be replaced with `Where(pair->!dic.ContainsKey(pair.Key)...` – Panagiotis Kanavos Jun 09 '15 at 10:46
  • 2
    Ok, `ToList()` is not good solution so I've changed the code. You can use `try { mainDic.AddRange(addDic); } catch { do something }` if you aren't sure for third method. The second method works perfectly. – ADM-IT Jun 09 '15 at 11:20
  • 1
    Thank you, I stole this. – HamsterWithPitchfork Feb 13 '20 at 09:32
20

In case someone comes across this question like myself - it's possible to achieve "AddRange" by using IEnumerable extension methods:

var combined =
    dict1.Union(dict2)
        .GroupBy(kvp => kvp.Key)
        .Select(grp => grp.First())
        .ToDictionary(kvp => kvp.Key, kvp => kvp.Value);

The main trick when combining dictionaries is dealing with the duplicate keys. In the code above it's the part .Select(grp => grp.First()). In this case it simply takes the first element from the group of duplicates but you can implement more sophisticated logic there if needed.

Rafal Zajac
  • 1,613
  • 1
  • 16
  • 13
  • What if `dict1` **doesn't** use the default equality comparer? – mjwills Sep 06 '17 at 06:11
  • Linq methods let you pass in IEqualityComparer when relevant: `var combined = dict1.Concat(dict2).GroupBy(kvp => kvp.Key, dict1.Comparer).ToDictionary(grp => grp.Key, grp=> grp.First(), dict1.Comparer);` – Kyle McClellan Mar 20 '18 at 19:32
12

My guess is lack of proper output to the user as to what happened. As you can't have repeating keys in a dictionaries, how would you handle merging two dictionary where some keys intersect? Sure you could say: "I don't care" but that's breaking the convention of returning false / throwing an exception for repeating keys.

Gal
  • 5,338
  • 5
  • 33
  • 55
  • 5
    How is that different from where you have a key-clash when you call `Add`, apart from that it can happen more than once. It would throw the same `ArgumentException` that `Add` does, surely? – nicodemus13 Apr 19 '12 at 16:38
  • 1
    @nicodemus13 Yes, but you would not know which key threw the Exception, only that SOME key was a repeat. – Gal Apr 23 '12 at 10:32
  • 1
    @Gal granted, but you could: return the name of the conflicting key in the exception message (useful to someone that knows what they're doing, I suppose...), OR you could put it as (part of?) the paramName argument to the ArgumentException you throw, OR-OR, you could create a new exception type (perhaps a generic enough option might be `NamedElementException`??), either thrown instead of or as the innerException of an ArgumentException, which specifies the named element that conflicts... a few different options, I'd say – Code Jockey Oct 22 '14 at 18:04
7

You could do this

Dictionary<string, string> dic = new Dictionary<string, string>();
// dictionary other items already added.
MethodThatReturnAnotherDic(dic);

public void MethodThatReturnAnotherDic(Dictionary<string, string> dic)
{
    dic.Add(.., ..);
}

or use a List for addrange and/or using the pattern above.

List<KeyValuePair<string, string>>
Valamas
  • 24,169
  • 25
  • 107
  • 177
  • 1
    Dictionary already has a constructor that [accepts another dictionary](https://msdn.microsoft.com/en-us/library/et0ke8sz(v=vs.110).aspx). – Panagiotis Kanavos Jun 09 '15 at 10:49
  • 1
    OP wants to addrange, not to clone a dictionary. As for the name of the method in my example `MethodThatReturnAnotherDic`. It comes from the OP. Please review the question and my answer again. – Valamas Jun 09 '15 at 21:12
4

Feel free to use extension method like this:

public static Dictionary<T, U> AddRange<T, U>(this Dictionary<T, U> destination, Dictionary<T, U> source)
{
  if (destination == null) destination = new Dictionary<T, U>();
  foreach (var e in source)
    destination.Add(e.Key, e.Value);
  return destination;
}
Franziee
  • 621
  • 11
  • 28
2

Just use Concat():

dic.Concat(MethodThatReturnAnotherDic());
Pang
  • 9,564
  • 146
  • 81
  • 122
thargan
  • 105
  • 3
  • 2
    `Dictionary` does not have a `Concat` method - `Concat` is coming from Linq and will return a collection of key-value pairs (with possibly duplicate keys), not a dictionary. – D Stanley Apr 09 '21 at 00:45
2

Why doesn't Dictionary have AddRange?

List.AddRange is specifically a "fast contiguous block copy" method of the kind seen across different languages for collections like lists, vectors or arrays, which have their data contiguously laid out in memory, i.e. with each element following the last, at regular offsets. Range hints at its internals, that is, only one range (of elements, of memory).

Dictionarys internally look very different to Lists. This is due to the way in which a hashtable (i.e. Dictionary) stores its entries: They're not contiguous in memory as we see in an array or a List, instead a Dicts elements are fragmented across multiple hash buckets which contain several entries, many empty, so you cannot just block-copy the whole range into e.g. a List or you'll get a bunch of empty entries which Dictionary usually hides from you through its interface.

Due to this fragmentation, we are left no choice but to manually iterate through the Dictionary's entries in order to extract only valid keys and values into a contiguous array, List or another Dict. See Microsoft's reference implementation, where CopyTo is thus implemented using for.

List.AddRange uses Array.Copy. This is similar to Buffer.BlockCopy whose equivalent in C is memcpy. It exists for performant copies of large blocks of contiguous data, all of which you want. This Adding is easily done at the end of a listB from listA, but the merging of two Dictionarys entries is not so trivial. And your proposal would need to handle that.

The method you conceptually propose would be useful, and is indeed possible to add. But to call it AddRange would be a misnomer. I would call it AddEntries, perhaps. And any implementation would have some interesting questions to solve, some of which others here have commented on.

Engineer
  • 8,529
  • 7
  • 65
  • 105
1

If you're dealing w/ a new Dictionary (and you don't have existing rows to lose), you can always use ToDictionary() from another list of objects.

So, in your case, you would do something like this:

Dictionary<string, string> dic = new Dictionary<string, string>();
dic = SomeList.ToDictionary(x => x.Attribute1, x => x.Attribute2);
WEFX
  • 8,298
  • 8
  • 66
  • 102
1

If you know you aren't going to have duplicate keys, you can do:

dic = dic.Union(MethodThatReturnAnotherDic()).ToDictionary(kvp => kvp.Key, kvp => kvp.Value);

It will throw an exception if there is a duplicate key/value pair.

I don't know why this isn't in the framework; should be. There's no uncertainty; just throw an exception. In the case of this code, it does throw an exception.

toddmo
  • 20,682
  • 14
  • 97
  • 107
  • What if the the original dictionary was created using `var caseInsensitiveDictionary = new Dictionary( StringComparer.OrdinalIgnoreCase);`? – mjwills Nov 24 '17 at 02:49
0

Here is an alternative solution using c# 7 ValueTuples (tuple literals)

public static class DictionaryExtensions
{
    public static Dictionary<TKey, TValue> AddRange<TKey, TValue>(this Dictionary<TKey, TValue> source,  IEnumerable<ValueTuple<TKey, TValue>> kvps)
    {
        foreach (var kvp in kvps)
            source.Add(kvp.Item1, kvp.Item2);

        return source;
    }

    public static void AddTo<TKey, TValue>(this IEnumerable<ValueTuple<TKey, TValue>> source, Dictionary<TKey, TValue> target)
    {
        target.AddRange(source);
    }
}

Used like

segments
    .Zip(values, (s, v) => (s.AsSpan().StartsWith("{") ? s.Trim('{', '}') : null, v))
    .Where(zip => zip.Item1 != null)
    .AddTo(queryParams);
Anders
  • 17,306
  • 10
  • 76
  • 144
0

As others have mentioned, the reason why Dictionary<TKey,TVal>.AddRange is not implemented is because there are various ways you might want to handle cases where you have duplicates. This is also the case for Collection or interfaces such as IDictionary<TKey,TVal>, ICollection<T>, etc.

Only List<T> implements it, and you will note that the IList<T> interface does not, for the same reasons: the expected behaviour when adding a range of values to a collection can vary broadly, depending on context.

The context of your question suggests you are not worried about duplicates, in which case you have a simple oneliner alternative, using Linq:

MethodThatReturnAnotherDic().ToList.ForEach(kvp => dic.Add(kvp.Key, kvp.Value));
Ama
  • 1,373
  • 10
  • 24
0

This is an extension function written by one of my colleagues and it saved my life today. HYG!

    /// <summary>
    /// Add key value pairs range to dictionary
    /// </summary>
    /// <param name="dictionary">current dictionary</param>
    /// <param name="range">new range to add</param>
    /// <typeparam name="TKey">dictionary key type</typeparam>
    /// <typeparam name="TValue">dictionary value type</typeparam>
    /// <returns>list of duplicate records that weren't added</returns>

public static IEnumerable<KeyValuePair<TKey, TValue>> AddRange<TKey, TValue>(this IDictionary<TKey, TValue> dictionary, IDictionary<TKey, TValue> range)
       {
        var duplicateRecords = new List<KeyValuePair<TKey, TValue>>();
        
        foreach (var item in range)
        {
            if (dictionary.ContainsKey(item.Key))
                duplicateRecords.Add(item);
            else
                dictionary.Add(item);
        }
        return duplicateRecords;
    }