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.

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" ]);

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

@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.

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.

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

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

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
})

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?

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?

@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.

I suggest using object notation, like TypeScript.

Like:

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

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])!;

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).

@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".

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.

I would like to add my take on the IEqualtiyComparer argument:

var dict = 
(new SomeEqualityComparer())
[
    // Whatever syntax we decide on here
    ["Cyrus"] = 21,
    ["Dustin"] = 22,
    ["Mads"] = 23,
]

This could also work for constructor parameters on other types, if that is found necessary.

What about using the JSON-like syntax for declaration:

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

But for pattern matching, use the indexer syntax suggested by @hez2010:

// Match a KV pair in the dictionary.
if (_nameToAge is { ["Cyrus": 69] })

// Match a property of the dictionary.
if (_nameToAge is { Length: 0 })

@glen-84 One of the goals of collection expressions were parity with pattern matching, so this (hopefully) won't happen.

This is probably as close to parity as you'll get when going with this JSON-like syntax. I think it's intuitive – you're matching elements of the dictionary, not the dictionary itself.

Otherwise it's back to option 1. 🙂

At least when it comes to expressions for creating a dictionary, in order to avoid the confusion of having too many options (especially ones that are almost the same), I think it would help to stay close to this existing dictionary initializer syntax:

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

For example:

[
   ["Cyrus"] = 21,
   ["Dustin"] = 22,
   ["Mads"] = 23,
]

This avoids the confusion of yet another style, and it separates key and value more clearly than the other existing collection initializer syntax:

new Dictionary<string, int>()
{
   // Meh for complex keys/values, especially when their expressions have commas and braces of their own
   { 111, new StudentName() { FirstName="Sachin", LastName="Karnik", ID=211 } },
   { 112, new StudentName() { FirstName="Dina", LastName="Salimzianova", ID=317 } },
   { 113, new StudentName() { FirstName="Andy", LastName="Ruth", ID=198 } },
};

For example:

[
   ["Cyrus"] = 21,
   ["Dustin"] = 22,
   ["Mads"] = 23,
]

This adds a lot of annoying extra characters to type, and tries to address a non-existent goal - to maintain similarity to existing approaches. Collection expressions (including dictionary expressions) are meant to come up with a standardized new syntax for all (most) collections, not try to continue older approaches. With respect to the syntax above, you can already do:

new()
{
   ["Cyrus"] = 21,
   ["Dustin"] = 22,
   ["Mads"] = 23,
};

Well, it's the same thing for lists and arrays. I can also currently do:

new() {1, 2, 3} // generates whatever collection target type is
new[] {1, 2, 3} // generates an array

But collection expressions were still added.

Just clarifying, which of these would we allow in pattern matching:

[
    // Type validation and accessing by value
    [string name] = 21,
    // Discarding
    [var _] = 22,
    // Accessing unknown values
    ["Mads"] = var age
]

But collection expressions were still added.

It saves typing even in the simple [1, 2, 3] scenario, but collection expressions also support spreads, which the old style syntaxes don't. Also, the language needs the { } for other constructs, and it's better to use [ ] for collections. Plus ability to target type interfaces, etc.
However, for dictionaries specifically, the ["Cyrus"] = 21 style of element is a good amount more ceremony per element than "Cyrus": 21, and that difference doesn't exist for regular collections. That's the argument I was making - why add more typing to new syntax, just to maintain similarity with older syntax which is explicitly being (soft-)replaced with the new syntax?

@TahirAhmadov

Collection expressions (including dictionary expressions) are meant to come up with a standardized new syntax for all (most) collections, not try to continue older approaches.

This syntax is well known. We can create a standard without reinventing the wheel. It's not a rule that we cant reuse old syntax.

This syntax is well known. We can create a standard without reinventing the wheel.

Personally, I never use the ["Cyrus"] = 21 "overwrite" syntax in my existing code specifically to keep my code safer - I prefer the Add semantics.
However, my personal preferences aside, the new "Cyrus": 21 syntax is not a difficult thing to learn in terms of introducing new syntax, and it is so intuitive, I'm frankly surprised by the amount of debate about it.
Also, I need to repeat - the new collection and dictionary expressions are meant to replace existing initializations, so it doesn't really matter that the old syntax is well known - think of it as something to forget going forward, really.

It's not a rule that we cant reuse old syntax.

There is no rule that we can't reuse old syntax, but there is zero reason to do so, and the old syntax is more typing. So, if it's worse than the proposed new one, and we are under no obligation to reuse old syntax, why reuse it?

Another thought - perhaps the ["Cyrus"] = 21 syntax can be used going forward, to explicitly switch to the "overwrite" mode? Basically, ["Cyrus": 21, ["Cyrus"] = 22] would not throw and instead have 22 for "Cyrus", as opposed to ["Cyrus": 21, "Cyrus": 22], which would throw.
PS. However this is probably a bad approach, because it doesn't address the question of switching a spread to "overwrite" semantics, and doesn't allow switching the whole dictionary expression to "overwrite", either.

@TahirAhmadov What makes it worse? If you have autocomplete, it's 1 extra character you have to type, 2 without. It's not the end of the world. It also conveys how it really works with the override semantics, which is far more useful than saving typing. And again, it doesn't have to replace the current to create a standard. We do not have to reinvent the wheel. ["Cyrus"] = 21 is just as intuitive.

@Ai-N3rd hmm that's incorrect. "Cyrus": 21 is one symbol - :. ["Cyrus"] = 21 is 3 symbols - [, ], and =. And auto-complete doesn't help here, because these are symbols - it would be very difficult for an IDE to predict when your key expression ends, at best it could suggest = for you after ], but even then you'd have to press Tab to accept it, so not really an improvement. So either way you look at it, it's 3 keystrokes per element instead of 1, multiply by say, 10 KVPs, and you're talking about 20 extra keystrokes for no good reason.

my concern with the extension method approach is that it seems like the elements would have to be copied into a holding collection that provides the IEnumerable and then copied into the dictionary, while a standard dictionary doesn't need a holding collection.

I believe the team intends on supporting extension methods that accept Span<T>/ReadOnlySpan<T> so that at worst it would require a temporary stack allocation:

See: #7622 (reply in thread)

@HaloFour
It seems like that would be fine for ["a":1, "b": 2].ToDictionary(comparer) but how would that work for ["a":1, ..x, "b":2, ..y].ToDictionary(comparer)?

@GabeSchaffer

but how would that work for ["a":1, ..x, "b":2, ..y].ToDictionary(comparer)?

That's a good question and I imagine that it's part of the conversation. I would expect that the buffer would be fully materialized before the extension method is invoked.

but how would that work for ["a":1, ..x, "b":2, ..y].ToDictionary(comparer)

It would work as it currently does for regular collection literals with spreads, using an array instead of stack allocating (via inline array). There could be more nuance in the future to decide between stack allocation and arrays.

but how would that work for ["a":1, ..x, "b":2, ..y].ToDictionary(comparer)

It would work as it currently does for regular collection literals with spreads, using an array instead of stack allocating (via inline array). There could be more nuance in the future to decide between stack allocation and arrays.

Currently T a = [1, ..x, 2, ..y]; is implemented like this:

T a = new T();
a.Add(1);
foreach (var temp in x)
    a.Add(temp);
a.Add(2);
foreach (var temp in y)
    a.Add(temp);

Ideally T a = [1, ..x, 2, ..y].With(comparer); is implemented like this:

T a = new T(comparer);
a.Add(1);
foreach (var temp in x)
    a.Add(temp);
a.Add(2);
foreach (var temp in y)
    a.Add(temp);
// or
TBuilder a_builder = new TBuilder(comparer);
a_builder.Add(1);
foreach (var temp in x)
    a_builder.Add(temp);
a_builder.Add(2);
foreach (var temp in y)
    a_builder.Add(temp);
T a = a_builder.AsT();

and not like this:

List<int> a_builder = new List<int>();
a_builder.Add(1);
foreach (var temp in x)
    a_builder.Add(temp);
a_builder.Add(2);
foreach (var temp in y)
    a_builder.Add(temp);
T a = new T(a, comparer);

Here's some really uncooked spaghetti, but what if that natural expression type could support some kind of empty generic struct that is used specifically to allow the extension method to return an empty collection into which the items would then be added?

public static Dictionary<T, TKey> WithComparer<T, TKey>(
    this CollectionLiteral<KeyValuePair<TKey, TValue>> literal,
    IEqualityComparer<TKey> comparer)
{
    return new Dictionary<T, TKey>(comparer);
}


// then
var dict = ["a": 1, "b": 2, ..others].WithComparer(StringComparer.CurrentCultureIgnoreCase);

// lowers (very roughly) into
var dict = DictionaryExtensions.WithComparer<string, int>(
    default(CollectionLiteral<KeyValuePair<string, int>>),
    StringComparer.CurrentCultureIgnoreCase);
dict["a"] = 1;
dict["b"] = 2;
foreach (var item in others) {
    dict[item.Key] = item.Value;
}

Here's some really uncooked spaghetti, but what if that natural expression type could support some kind of empty generic struct that is used specifically to allow the extension method to return an empty collection into which the items would then be added?

public static Dictionary<T, TKey> WithComparer<T, TKey>(
    this CollectionLiteral<KeyValuePair<TKey, TValue>> literal,
    IEqualityComparer<TKey> comparer)
{
    return new Dictionary<T, TKey>(comparer);
}


// then
var dict = ["a": 1, "b": 2, ..others].WithComparer(StringComparer.CurrentCultureIgnoreCase);

// lowers (very roughly) into
var dict = DictionaryExtensions.WithComparer<string, int>(
    default(CollectionLiteral<KeyValuePair<string, int>>),
    StringComparer.CurrentCultureIgnoreCase);
dict["a"] = 1;
dict["b"] = 2;
foreach (var item in others) {
    dict[item.Key] = item.Value;
}

Using extension methods (or extension methods syntax) for this feels misleading to me though... When using normal extension methods, one expects that it will apply "to the result of the expression to the left". Yet, here we are proposing some magical change of the order of operations, and the extension now applies to something that exist before the actual expression is computed.

What if now I want to create an extension that applies after the collection is created? I'd use the explicit interface of the final collection instead of this custom CollectionLiteral type. That feels incredibly weird to me.

Not a fan of that aspect at all. I'd rather have custom syntax at this point to avoid the confusion in behavior and special casing something that already exists.

Here's some really uncooked spaghetti, but what if that natural expression type could support some kind of empty generic struct that is used specifically to allow the extension method to return an empty collection into which the items would then be added?

I think I prefer something akin to InterpolatedStringHandler. My suggestion is for something like this:

[CollectionExpressionHandler]
public ref struct DictionaryExpressionHandler<TKey, TValue>
{
    Dictionary<TKey, TValue> builder;
    public DictionaryExpressionHandler(IEqualityComparer<TKey> comparer) => builder = new(comparer);
    public void Add(KeyValuePair<TKey, TValue> pair) => builder[pair.Key] = pair.Value;
    internal Dictionary<TKey, TValue> GetCollection() => builder;
}

public static Dictionary<TKey, TValue> WithComparer<TKey, TValue>(
    this [CollectionExpressionHandlerArgument("comparer")] DictionaryExpressionHandler<TKey, TValue> handler,
    StringComparer comparer) => handler.GetCollection();

// then
var dict = ["a": 1, "b": 2, ..others].WithComparer(StringComparer.CurrentCultureIgnoreCase);

// would lower to something like this:
var handler = new DictionaryExpressionHandler<string, int>(StringComparer.CurrentCultureIgnoreCase);
handler.Add(new KeyValuePair<string, int>("a", 1));
handler.Add(new KeyValuePair<string, int>("b", 2));
foreach (var pair in others)
    hander.Add(pair);
var dict = handler.WithComparer(StringComparer.CurrentCultureIgnoreCase);

From what i see dictionary already has copy constructors with comparer variant will these be optimized whenever used directly with dict expressions? Like:

var dict = new Dictionary<string, string>(["prop1" : "value", "prop2" : "value"], comparer);

If yes you could use real alias or implicit extensions as fake alias to make it decently short and still equally performant to hand-written code. Although this has a downside of generics not being inferred and either requiring them to be spelled on each use site or making 1 alias per generic combination used. The upside is there no new pattern since it uses preexisting copy constructors

This one seems to have gotten snowed under by new suggestions, but it was quite intuitive and seemed to attract no opposition:

Dictionary<string,string> d1 = [new: (comparer), "a": "b"];
FrozenDictionary<string,string> d2 = [new: (comparer, true), "a": "b"];
// maybe use "init" so that it's clear we're not calling the collection's ctor?
FrozenDictionary<string,string> d2 = [init: (comparer, true), "a": "b"]; 

It also features the nice property of reducing cognitive load by putting the constructor parameters first. Before we get to the meat, which could span many lines, it gets the collection's configuration out of the way. (And that configuration may well determine how we read the keys, e.g. whether the presence of both "a" and "A" sets off alarm bells in our heads.)

Conversely, imagine code reviewing an initializer without this property, needing to scrutinize the elements, all the while juggling in your head the thought of "shouldn't this need a case-insensitive comparer"...

@Timovzl

...but it was quite intuitive and seemed to attract no opposition

I'm opposed to it on the grounds that it is special cased to collection literals.

I don't see a need for the syntax to be exclusive to only collection literals. It makes the language unnecessarily complex by introducing lots of equivalent constructs that are not orthogonal later when similar needs are seen with other types of literals.

A simple modification would allow for a more reusable syntax:

Dictionary<string,string> d1 = new: (comparer) ["a": "b"];
FrozenDictionary<string,string> d2 = new: (comparer, true) ["a": "b"];
// maybe use "init" so that it's clear we're not calling the collection's ctor?
FrozenDictionary<string,string> d2 = init: (comparer, true) ["a": "b"]; 

I'm opposed to it on the grounds that it is special cased to collection literals.

Collection literals are not trying to create composable syntax for all features. In a very real sense, a major pillar of them is that they are not trying to be built out of orthogonal concepts (which generally need to be much more verbose to meet generalized needs). Collectoin literals realize that collections are important enough to warrant specialized syntax for the collections-domain.

@CyrusNajmabadi

I'm opposed to it on the grounds that it is special cased to collection literals.

Collection literals are not trying to create composable syntax for all features. In a very real sense, a major pillar of them is that they are not trying to be built out of orthogonal concepts (which generally need to be much more verbose to meet generalized needs). Collectoin literals realize that collections are important enough to warrant specialized syntax for the collections-domain.

I don't quite follow how a major pillar in the design is to actively avoid using orthogonal syntax... that's just crazy to me, but fair enough.

Given two equally expressive and intuitive syntaxes, one that is orthogonal/general purpose, and the other that is completely coupled to collection literals only, I fail to see the appeal of picking the latter. To me, that's just shooting oneself in the foot as you just purposefully put yourself in a corner that will force you to come up with yet another initialization syntax later down the line making the language worse to digest.

Specifically with the example from @TahirAhmadov above, is my suggestion that less intuitive or harder to use? It surely enough feels basically identical to me, it just moves some characters out of the [...] while preserving everything else: one is tied to collection expressions and the other isn't.

Specialized syntax should only win if it really is vastly more intuitive/simple/easy to use than the general purpose one IMHO, otherwise there is just no reason to go with it. Yet, you are apparently locked in the idea that it will be specific... even though it hasn't been defined yet.

I don't quite follow how a major pillar in the design is to actively avoid using orthogonal syntax

A core virtue here is brevity. We already have verbose options available to us today:-)

I fail to see the appeal of picking the latter.

Only if they are truly equal on every other dimension. That remains to be seen. A better syntax, for collections only, would likely still be preferred.

is my suggestion that less intuitive or harder to use

To me, it is. Especially given that we already have a new(...) form. Now we'd have new:(...) form as well. This is not a positive for me.

I fail to see the appeal of picking the latter.

Only if they are truly equal on every other dimension. That remains to be seen. A better syntax, for collections only, would likely still be preferred.

Fair.

is my suggestion that less intuitive or harder to use

To me, it is. Especially given that we already have a new(...) form. Now we'd have new:(...) form as well. This is not a positive for me.

Oh, just to be clear, I was asking that question when comparing it to @TahirAhmadov's original proposed syntax, not in general. I also dislike the new: syntax. The point was that "if you are doing it that way, at least move the elements outside of the array literal so it could be reused for other use cases later".

Currently when we want to create e.g. a Dictionary<string, double> we do something like this:

Dictionary<string, double> airComponents = new(capacity, comparer) {
        {  "CO", 10.0 },
        {  "CO2", 200.0 },
}

How will we be able to utilize capacity and comparer parameters in the proposed syntax?

Something like this maybe in order to be as close to the existing collection initialization?

Dictionary<string, double> airComponents = [
    new("CO",  10.0),
    new("CO2", 200.0)
].WithCapacity(...).WithComparer(....)

@tzographos see these:
#7822 (comment)
#7822 (comment)
It's based on a proposed syntax I noticed in LDM notes but I can't find that link now.

Given that there is no branch in Roslyn for this (that I can see), is it safe to say this won't be a C# 13 feature?

Correct.

Not suitable for practical usage, of course, but there is an another unsafe syntactically correct way of dictionary creation via anonymous type and reflection

var dictionary = new
{
    Cyrus = 21,
    Dastin = 22,
    Mads = 23,
}
.ToDictionary<int>();

Console.WriteLine(dictionary["Cyrus"]); // 21

public static class Ext
{
    public static Dictionary<string, TValue> ToDictionary<TValue>(this object item) => item
        .GetType()
        .GetProperties()
        .ToDictionary(p => p.Name, p => (TValue)p.GetValue(item))
        ;
}

So, there are possible relaxations of syntax

var dictionary = new Dictionary<string, int>
{
    Cyrus = 21, // instead: ["Cyrus"] = 21,
    Dastin = 22,  // instead: "Dastin" = 21,
    "Mads" = 23, // allowed
    "Key With Spaces" = 24,
};

Not sure that it is a value proposal, but may be considered for fun.

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,
];

We already have two:

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

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.

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.

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.