[Proposal]: Dictionary expressions

[CyrusNajmabadi]

Dictionary Expressions

• tracking issue: [Proposal]: Dictionary expressions #8659

Summary

Collection Expressions were added in C# 12. They enabled a lightweight syntax [e1, e2, e3, .. c1] to create many types of linearly sequenced collections, with similar construction semantics to the existing [p1, p2, .. p3] pattern matching construct.

The original plan for collection expressions was for them to support "dictionary" types and values as well. However, that was pulled out of C# 12 for timing reasons. For C# 13 we would to bring back that support, with an initial suggested syntax of [k1: v1, k2: v2, .. d1]. As a simple example:

private readonly Dictionary<string, int> _nameToAge = [
    "Cyrus": 21,
    "Dustin": 22,
    "Mads": 23,
];

The expectation here would be that this support would closely track the design of collection expressions, with just additions to that specification to support this k:v element syntax, and to support dictionary-like types as the targets of these expressions.

Motivation

• Collection-like values are hugely present in programming, algorithms, and especially in the C#/.NET ecosystem. Nearly all programs will utilize these values to store data and send or receive data from other components. Currently, almost all C# programs must use many different and unfortunately verbose approaches to create instances of such values.

• An examination of the ecosystem (public repos, nuget packages, and private codebases we have access to), indicate that dictionaries are used as a collection type in APIs around 15% of the time. While not nearly as ever-present as the sequenced collections (like arrays, spans, lists, and so on), this is still substantial, and warrants the equivalently pleasant construction provided by collection-expressions.

• Like with linear collections, there are numerous different types of dictionary-like types in the .net ecosystem. This includes, but is not limited to, simply constructed dictionaries like Dictionary<TKey, TValue> and ConcurrentDictionary<TKey, TValue>, but also interfaces like IDictionary<TKey, TValue> and IReadOnlyDictionary<TKey, TValue>, as well as immutable versions like `ImmutableDictionary<TKey, TValue>. Supporting all these common forms is a goal for these expressions.

[KennethHoff]

As noted by open question 2, I think losing support for IEqualityComparer - especially for string dictionaries - would be very unfortunate. For me personally equality comparisons is one of the primary reasons I use dictionaries over other data structures.

[HaloFour]

Would an extension method not suffice here?

var dictionary = [ "foo": "bar", "fizz": "buzz" ].WithComparer(StringComparer.OrdinalIgnoreCase);

// or

var dictionary  = StringComparer.OrdinalIgnoreCase.CreateDictionary([ "foo": "bar", "fizz": "buzz" ]);

[GabeSchaffer]

Would an extension method approach to specifying comparers be able work without creating a second dictionary?

[CyrusNajmabadi]

@GabeSchaffer Likely yes (though we would still need to get extensions working with collection exprs). Specifically, the keys/values in the expr woudl likely be passed to the extension method as a ReadOnlySpan of KeyValuePairs. These would normally just be on the stack, and would be given as a contiguous chunk of data for the dictionary to create its internal storage from once.

[GabeSchaffer]

Apologies for my lack of understanding, but it seems like a builder approach to augmentation could be made to work, like with String.Create.

That seems like it could make a syntax like this possible:

var dictionary = Dictionary.Create(StringComparer.OrdinalIgnoreCase, [ "foo": "bar", "fizz": "buzz" ]);

Another options that seems feasible is to allow constructor arguments to be specified in parens after the collection expression:

[ "foo": "bar", "fizz": "buzz" ](StringComparer.OrdinalIgnoreCase) // function call syntax for passing ctor args

An uglier possibility is to use a semicolon:

[ "foo": "bar", "fizz": "buzz"; StringComparer.OrdinalIgnoreCase ] // ; delimits comparer

I think if we want to have hope of being able to specify a comparer in a pattern, the latter two are better.

[rjgotten]

Another options that seems feasible is to allow constructor arguments to be specified in parens after the collection expression

Or take a page from the book of record,
offering a short-hand default of passing an IEqualityComparer<TKey>

[ "foo": "bar", "fizz": "buzz" ] with StringComparer.OrdinalIgnoreCase;

or an expanded form that can bind any constructor parameter for more custom cases, like say.. when you expect more elements to be added to a dictionary and you know the upper limit:

[ "foo": "bar", "fizz": "buzz" ] with (comparer : StringComparer.OrdinalIgnoreCase, capacity : 20);

[edit]
Never mind; seems this was already considered and shot down. One of the design criteria now being that everything is contained within the [] collection expression braces.

[GabeSchaffer]

Something else, which I hadn't considered at the time of my previous post, is that C# always evaluates subexpressions left-to-right -- which means that the keys and values would have to be evaluated before the comparer or capacity. That means it would have to compute all the key-value pairs and hold them somewhere before it could call the constructor.

In order for ["first": x = 1, "second": x++, "third": x++] with (capacity: x) to work the way a C# programmer expects, it would need to have a place to store the different values of x until it computed the capacity, then copy those values in. The alternative is to evaluate the capacity first, and end up with the wrong value.

The first option makes the dictionary expressions perform worse than current ways to do it, and the second option ends up with the wrong capacity. Since both are contrary to a typical programmers expectations, the "arguments last" options are all off the table.

[Perksey]

Wow I had no idea the C# team were so young ;)

private readonly Dictionary<string, int> _nameToAge = [
    "Cyrus": 21,
    "Dustin": 22,
    "Mads": 23,
];

[jnm2]

Makes for good eyesight. So they can, yknow...

[pinkfloydx33]

Makes for good eyesight. So they can, yknow...

See sharp?

[hez2010]

How about reusing the existing dictionary syntax?

Given that we already have

var dict = new Dictionary<K, V> { [key] = value }

We can somehow use a similar syntax:

var dict = { [key]: value }

This is also matching how TypeScript defines an interface with indexed field:

interface Foo {
    [key: string]: number;
}

And we can even support dictionary patterns along with existing patterns as well:

var obj = new C();

if (obj is {
    [string key]: 42,
    ["foo"]: int value,
    SomeProp: float x
}) ... // matching an object which has a indexed value 42 while its key is string, and a key "foo" whose value is int

class C
{
    public float SomeProp { get; }
    public int this[string arg] => ...
}

As well as the case where the indexer has multiple parameters:

if (obj is {
    ["foo", "bar"]: 42
})

[TahirAhmadov]

Specifically, the keys/values in the expr woudl likely be passed to the extension method as a ReadOnlySpan of KeyValuePairs.

What about spreads, those will have to be iterated and placed on the stack before calling the extension method? Or is there a way to pass them in somehow?

[GabeSchaffer]

Specifically, the keys/values in the expr woudl likely be passed to the extension method as a ReadOnlySpan of KeyValuePairs.

What about spreads, those will have to be iterated and placed on the stack before calling the extension method? Or is there a way to pass them in somehow?

I don't see how that can be implemented in any way other than to copy every element into a contiguous array in order to create a ReadOnlySpan. Because if the elements aren't contiguous, it's not a span, right?

[mpawelski]

@hez2010

How about reusing the existing dictionary syntax?

Given that we already have

var dict = new Dictionary<K, V> { [key] = value }

We can somehow use a similar syntax:

var dict = { [key]: value }

I think dictionary-like objects that have only one indexer are so common that it's worth to consider special, more succinct, syntax that doesn't require unnecessary [ and ]. Such as the one proposed in this thread.

Actually, your proposed syntax is not far from what we can do now in C#:

Dictionary<string, int> dict = new() { 
    ["aaa"] = 1, 
    ["bbb"] = 1
};

And we can even support dictionary patterns along with existing patterns as well:

var obj = new C();

if (obj is {
    [string key]: 42,
    ["foo"]: int value,
    SomeProp: float x
}) ... // matching an object which has a indexed value 42 while its key is string, and a key "foo" whose value is int

class C
{
    public float SomeProp { get; }
    public int this[string arg] => ...
}

As well as the case where the indexer has multiple parameters:

if (obj is {
    ["foo", "bar"]: 42
})

Actually I was kinda surprised that C# doesn't have pattern matching for indexers. This code doesn't work:

Dictionary<string, int> dict = new() { 
    ["aaa"] = 1, 
    ["bbb"] = 2
};

if (dict is { ["aaa"] : 1 })
{
}

But this feels looks like another "pattern matching improvements" feature, not strictly related to dictionary expressions we discuss in this thread.

[scarletquasar]

I suggest using object notation, like TypeScript.

Like:

{
    Type = "Person",
    Name = "John"
}

[TahirAhmadov]

Can we make the "add/overwrite" be switchable? Say, we default to the safe "add" approach, and if overwrite is desired:

var d = [(k1: v1)!, (..d1)!];

Here, ! means "overwrite".
Frankly, I'm not crazy about this syntax, but I couldn't come up with anything better at the moment (admittedly, I thought about it for a few minutes only).
However, syntax aside, I'd still like to raise this as a suggestion.

PS. In addition to the above, if it should be "overwrite" for the whole list:

var d = ([k1: v1, ..d1])!;

[colejohnson66]

That syntax looks a bit weird. If an "or overwrite" operation was added, I'd prefer to augment the with syntax:

IDictionary<string, string> d = GetDictionary();
(string k, string v) = GetNewKVP();
IDictionary<string, string> d2 = d with { [k1]: v1 };

But maybe that would be confusing, as one would have to remember that spreading is adding and with is overwrite (or add if missing).

[TahirAhmadov]

@colejohnson66 with your approach, you would always have to create a temp dictionary variable to then "overwrite" things onto it to produce the final desired result, which effectively changes it from a "collection expression" to a "procedural code block".

[alrz]

You can do this today

Dictionary<string, int> _nameToAge = new(OptionalComparer) {
    ["Cyrus"] = 21,
    ["Dustin"] = 22,
    ["Mads"] = 23,
};

or just [new(key ,value)] given an extension Add(this Dictionary, KeyValuePair).

I'd rather see dictionary/indexer patterns to complete the matching side of the existing [e]=v initialization syntax. Meanwhile, I think stronger type inference could help a lot within the existing syntax for more concise maps.

var x = new Dictionary() { .. };

There's endless optimization possibilities for collection expressions, not so much with dictionaries, and spreads with maps are just confusing or so rare at best.

Having said that, I think immutable dictionaries could use some less awkward initialization API, if possible.

[Atulin]

Not sure about yet another notation for dictionaries, to be honest. We already have two:

var dict = new Dictionary<string, int>() {
    { "one", 1 },
    { "two", 2 },
    { "three", 3 },
};

and

var dict = new Dictionary<string, int>() {
    ["one"] = 1,
    ["two"] = 2,
    ["three"] = 3,
};

and the proposal would add a third notation?

As much as I am a fan of adding some collection literal syntax to dictionaries, I'd rather reuse one of the existing notations, ideally the latter:

new Dictionary<string, int> dict = [
    ["one"] = 1,
    ["two"] = 2,
    ["three"] = 3,
];

[CyrusNajmabadi]

We already have two:

This is not two syntaxes. Those are the existing syntaxes for Add vs Indexing. They serve different purposes.

[CyrusNajmabadi]

and the proposal would add a ... notation?

Yes. Like with collection expressions, the point would be to be terse. If it's not terse, you can use the existing syntax.

[ ["one"] = 1

This is syntactically ambiguous, and it needs two more tokens than the simpler k:v syntax.

Brevity was a primary goal of collection expressions. We don't want to roll that back extending to the simple case of dictionaries.

[Atulin]

This is not two syntaxes. Those are the existing syntaxes for Add vs Indexing. They serve different purposes.

They both serve the same purpose of initializing a dictionary literal. Sure, technically one of them compiles down to .Add("x", 0) and another to ["x"] = 0;, but their purpose is the exact same.

You're right that k:v is more terse that [k]=v or {k,v}, there's no doubt about it. I'd simply rather not have a notation that's inconsistent with either of the two existing ones. It's like, I don't know, having a collection expression use | for item separator instead of ,.

It's ultimately no big deal, and I'll use whatever the syntax ends up being, but I still wanted to throw in my two cents.

[hez2010]

I would still like to resolve this in a more general way: instead of dictionary expressions which only treat Dictionary specially, we introduce "indexable expressions", and particularly, Dictionary is an indexable object which only takes one parameter as key.

Then we use the following syntax:

T obj = {
    [key, ...]: value
}

For dictionary or any type which has an indexer with only 1 param set_Item(arg1), we can write the expression like:

Foo1 obj = {
    ["foo"]: "bar"
}

class Foo1
{
    public string this[string key] { set => ... }
}

And for types have an indexer with 2 params set_Item(arg1, arg2), we can write the expression like:

Foo2 obj = {
    ["foo", 42]: "bar"
}

class Foo2
{
    public string this[string key1, int key2] { set => ... }
}

This will allow us to use arbitrary number of keys.

[AArnott]

Unlike linear-collections, augmenting a dictionary is a much more common practice. For example, providing a suitable IEqualityComparer. Should that be something supported somehow in this syntax. Or would/should that require falling back out to a normal instantiation?

Some linear collections do take comparers. e.g. SortedSet<T> which has no keys, but has a Comparer<T> anyway, with a default constructor and one that takes the Comparer<T>.

So whatever syntax you may come up with for maps, ideally it would work for vectors too.

[CyrusNajmabadi]

Unlike linear-collections, augmenting a dictionary is a much more common practice. For example, providing a suitable IEqualityComparer. Should that be something supported somehow in this syntax. Or would/should that require falling back out to a normal instantiation?

Some linear collections do take comparers. e.g. SortedSet<T> which has no keys, but has a Comparer<T> anyway, with a default constructor and one that takes the Comparer<T>.

So whatever syntax you may come up with for maps, ideally it would work for vectors too.

The latest proposal spec makes this point as well. It's something we will discuss.

[alrz]

From: https://github.com/dotnet/csharplang/blob/main/proposals/collection-expression-arguments.md

HashSet<string> s = [...] with ...;

I remember there was a request to specify the comparer on switch as well (I couldn't find the issue/discussion on that unfortunately),

switch (e) with (StringComparer.OrdinalIgnoreCase) {..}

map ??= new Dictionary<string /*constant pattern*/, int /* case index */>(comparer) {..};
if (map.TryGetValue(e, out var index)) /* jump to section */ else /* jump to default */;

Could that possibly extended to switch?

[useerup]

May I suggest an alternative syntax for comparer support and support for other constructor/factory parameters such as capacity:

Dictionary<string, int> caseInsensitiveMap new(StringComparer.CaseInsensitive) = [.. existingMap];

or perhaps just

Dictionary<string, int> caseInsensitiveMap(StringComparer.CaseInsensitive) = [.. existingMap];

A declaration of an identifier can be followed by the keyword new and a list of parameters, excluding the parameter that follows the = symbol. The expression following = is then assumed to be the first parameter. This is to align the proposal with the convention that seems to be used for collection constructors, where the items are the first parameter and any "extra" parameters such as comparer, capacity, settings etc follows the actual items parameter.

A variant may be to leave out even the new keyword. The fact that it is a declaration may be enough to disambiguate it from function application.

We could also consider using the discard _ or this keyword in the parameter list if we wanted to explicitly indicate the position of the parameter that follows the = symbol:

Dictionary<string, int> caseInsensitiveMap(_,StringComparer.CaseInsensitive) = [.. existingMap];

[TahirAhmadov]

What if the dictionary expression needs to be appear somewhere other than the right side of an assignment statement?

[useerup]

I think the proposal is already dependent on having a target type from the declaration?

[TahirAhmadov]

Target type also exists when passing a value to a method parameter, when returning something from a method, and probably in other scenarios, as well.

[jnm2]

Yep, when casting, when specifying a tuple element, when assigning to an indexer, in an arm of a switch expression or conditional expression, and many many more.

[StephenCleary]

There are two places where I really want nicer syntax:

• Activity.SetTag for setting a bunch of tags at once.
• ILogger.BeginScope<TState> for passing a bunch of tags at once.

Can dictionary expressions be used in these places?

[slang25]

+1 I would love to see this work with TagList so you get the most performant thing without needing to know about the existence of TagList

[StephenCleary]

Yes, thank you! I couldn't remember what TagList was called. But +1 for TagList support for sure!

[jnm2]

Just eyeballing the TagList type, it looks like the syntax [new(k1, v1), new(k2, v2), .. existingDict] currently works.

To opt in to the syntax [k1: v1, k2: v2, .. existingDict], the current design of dictionary expressions requires someone to add a (maybe extension?) object? this[string] indexer on TagList. In addition, either this indexer needs to have a setter, or the TagList type needs a CollectionBuilder attribute pointing to a static Create method taking ReadOnlySpan<KeyValuePair<string, object?>>.

[TahirAhmadov]

I would like to bring up dictionary pattern matching. I understand there is a concern about issues with syntax, but I'm not sure what they are?

var dict = new Dictionary<string, int> { ... };
if(dict is ["a": int a]) { } // has one KVP only
if(dict is ["a": int a, ..]) { } // has the specified KVP, and zero or more other KVPs
object obj = dict;
if(obj is Dictionary<string, int> [ "a": int a ]) { } // same idea

It's entirely possible I'm missing something obvious, so forgive me for (potentially) asking a silly question.

PS. I kind of miss this with regex Match: if(PersonRegex().Match(str) is { Success: true, Groups: [ "First": { Value: string first } ] }) { ... }

[RikkiGibson]

We could do expr is Dictionary<string, int> ["a": int a], but it feels like expr is Dictionary<string, int> and ["a": int a] would work fine.

[jnm2]

Would the stronger type info travel across the and so that we can find the indexer in the dict pattern?

[TahirAhmadov]

I think you would already be able to do expr is Dictionary<string, int> dict && dict is ["a": int a], I mean it is some boilerplate, but not the end of the world. Does this happen often enough to justify shortening? I'm not sure.

[RikkiGibson]

Would the stronger type info travel across the and so that we can find the indexer in the dict pattern?

Yes. That happens in general for e.g. expr is MyType and { MyProp: ... }. Or obj is int and < 10.

[TahirAhmadov]

I just thought about some other questions, do we support these?

if(dict is [_: int b]) { } // has one KVP, any key, value is int
if(dict is ["a": int a, _: _, ..]) { } // has "a": int a, one more KVP with any key/value, and zero or more other KVPs
// etc.

[TahirAhmadov]

I don't recall this being discussed previously - is it possible to compile-time check if the keys are unique when they are literals or constants? And I guess the same question applies to types like HashSet<T>.
This would be very helpful when making "constant" (static readonly) dictionaries (especially FrozenDictionary<,>) for mapping purposes - when writing something similar as a switch statement or expression, the compiler rightfully errors on duplicate cases, but the moment you change to a dictionary (there are reasons why it can be better than a switch in some situations), the compile time checking is lost with the current new() { { "k", "v" } } syntax.

[rjgotten]

It's entirely up to the dictionary (and the comparer it uses).

It's only up to the comparer being used, actually, in the sense that that defines what 'duplicate' means.
IDictionary<TKey,TValue>.Add itself is documented at the interface level as needing to throw ArgumentException on keys that already exist in the dictionary. So any implementation choosing to not do that, is non-conformant and in error.

[CyrusNajmabadi]

1. IDictionary has no special meaning to the language (or to this feature). Outside of us being willing to generate a Dict<,> when targeting that type.
2. The language feature does not compile down to .Add calls. We explicitly call into the this[] indexer, which practically always is ok with dupe keys.

[jnm2]

Just because no one got around to analyzing uniqueness of keys in collection initializers, does not strike me as a great reason not to start. It feels very in line with the help around analyzing uniqueness of switch patterns and so on. It can be done on well-known dictionary types and comparers.

[CyrusNajmabadi]

We do not have the resourcing for this task, and it woudl take away from more critical work that needs to be done. This is a very good reason for us to not add another component that we will then have to support and maintain for another 10+ years.

We built an extensible analysis framework for a reason. It is so that hte community can invest in analysis areas deemed worthwhile. If we make an extensible analysis framework, just for us to have to write and maintain the analyzers ourselves, then we're not addressing the core problem.

[jnm2]

Sure. It would make sense in the box, but would be equally as effective coming from the community!

[malisancube]

Dictionary<string, int> numbers = (StringComparer.InvariantCultureIgnore)["one": 1, "two", "three" : 4]; would be better than mixing elements and initialization args

[CyrusNajmabadi]

(Type)[expr] is already legal syntax, and is already used in the wild. It's how you cast a collection to a particular type.

[jnm2]

Or, how you call an indexer on an expression generally: (expr)[index]

Also, what do you do with multiple arguments? That's indexing into a tuple: (comparer, capacity: 42)[k: v]

[MegaEgorik]

Maybe just add another constructor overload? Something like this:
Dictionary<string, int> numbers = new(someComparer, "one": 1, "two": 2, "three": 3);
The first argument is the comparer, and the second is params IEnumerable<KeyValuePair<string, int>>
What do you think?

[CyrusNajmabadi]

That would not work for things like collection-builders. Also, we don't want to associate 'new' with this feature as 'new' has traditionally always meant you're getting a new object instance, which doesn't have to be the case at all with collection expressions (for example, the impl can returned cached instances if it wants).

[rosieks]

How dictionary expression are going to work with nested dictionaries. Let say like that:

var data = [
    "name": "default",
    "config": [
      "path": "/tmp/config"
    ]
]

Does code like that going to work? What type will be type of data and config. I work with Pulumi and there is plenty of dictionaries so I hope it will be possible to simply code.

[jnm2]

@mikernet The element type for your ListDictionary is https://www.singulink.com/Docs/Singulink.Collections/api/Singulink.Collections.ListDictionary-2.ValueList.html, which can be targeted by collection expressions (using the same codegen as for collection initializers). So for using nexted collection expressions for the values of your dictionary entries, it looks like you're all good there.

Where you're not currently good is that collection expressions ("dictionary expressions") can't create a ListDictionary instance. In order to enable that, you'll need to do one of:

• Make the instance mutable by adding a setter to your this[TKey] indexer
• Or, add a CollectionBuilder attribute to the ListDictionary type which points to a static Create method which receives a span of items to add to the dictionary and returns a ListDictionary instance. https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/collection-expressions#collection-builder

Once that is done, and once the dictionary expressions feature ships, you'll be able to use [k1: [v1, v2, v3]] syntax to instantiate your ListDictionary type.

[jnm2]

When it comes to list patterns, that is already supported with your existing ListDictionary and ValueList types. All you need for a list pattern is for the type to be countable (having an int Count/Length property) and indexable (having a this[int] or this[Index] member).

There are no indexer patterns or dictionary patterns in the language, though.

[rosieks]

So to make it working I need something like that:

Dictionary<string, object> data = [
    "name": "default",
    "config": (Dictionary<string, object>)[
      "path": "/tmp/config"
    ]
]

[jnm2]

Correct. Natural types for collection expressions would allow those to be inferred, though even then you'd probably still need some (object) casts so it doesn't infer Dictionary<string, string> or have conflicts.

[rosieks]

Is there any proposal for natural types for collection expression?