Update CL-2024-01-23.md

meetings/working-groups/collection-literals/CL-2024-01-23.md

@@ -29,7 +29,9 @@ Broken down, we see important design needing to be made in the following areas:
 
     As part of this, we want to figure out what expressions elements can mix/match with what target types.  For example (as shown above) can a `k:v` element be used with a sequence-type?  Can a normal expression element be used with a dictionary type (e.g. `Dictionary<string, int> x = [kvp1, kvp2]`)?
 
-3. The semantics of dictionary expressions wrt 'adding' vs 'overwriting' key/value associations.
+    When the form `[k:v]` is used, it's possible that users will expect to be able to index into the resulting collection with `k` and get `v`. But, for `List<KeyValuePair<int, int>> kvps = [1: 2, 3: 4]`, `kvps[1]` will not yield `2`.
+
+2. The semantics of dictionary expressions wrt 'adding' vs 'overwriting' key/value associations.
 
     We could go with the simple approach of adding each association one at a time, left to right.  This would align both with how collection-expressions work today for sequence collections, as well as how dictionary-initializers work (e.g. `new D<string, int> { { "mads": 21 }, { "cyrus": 22 } }`).  However, there is a definite feeling that this approach is limiting and cuts out certain valuable scenarios, all specifically around `spread` elements.  For example:
 
@@ -48,7 +50,7 @@ Broken down, we see important design needing to be made in the following areas:
     
     If we do decide on 'overwrite' semantics, we could consider having the compiler warn though in the case of multiple `k:v` elements, with the same constant value for `k`.
 
-4. Adopting `JSON` syntax here.
+3. Adopting `JSON` syntax here.
 
     Specifically, allowing `{ "key": value }` to work as legal dictionary-expression syntax.  Working group leans no, but we definitely want to run by LDM for thoughts.
 
@@ -60,7 +62,7 @@ Broken down, we see important design needing to be made in the following areas:
         - Impacts our future design space around `{...}` (for example, expression blocks).
         - Is very difficult to have pattern-parity.  `{ k: ... }` is already legal as a property pattern.  Needing that to work as a dictionary-pattern is non-trivial (and potentially very confusing for users).
 
-5. Mechanisms to specify a `comparer` or `capacity` for a dictionary.
+4. Mechanisms to specify a `comparer` or `capacity` for a dictionary.
 
     Discussions with the community have already indicated a strong desire to be able to specify these values (esp. the `comparer`). We think this is common enough to want to be able to have support, ideally in a way that doesn't feel like one is taking a big step back wrt brevity and simplicity of the dictionary-expression.  Importantly, it would be a shame if the collection-expression form weren't better than a user just using a dictionary-initializer today (e.g. `new(myComparer) { { "mads": 21 } }`).
 
@@ -70,11 +72,11 @@ Broken down, we see important design needing to be made in the following areas:
 
     - `[new: (comparer, capacity), "mads": 21]`.  A special construct allowing one to state what arguments to pass to the constructor.  Note: this would likely be beneficial for normal sequence-collections as well.  As `new` is already a keyword and `new:` is not legal in the language today, this would have no concerns around ambiguity.
 
-6. Targeting interfaces.
+5. Targeting interfaces.
 
     Like with sequence-expressions, we believe that dictionary-expressions should be able to at least target the well known type `IDictionary<TKey, TValue>` as well as `IReadOnlyDictionary<TKey, TValue>`. We expect to take a similar approach to what we did with sequence-expressions, where we choose `Dictionary<TKey, TValue>` for the former, and allow the compiler to synthesize a read-only type for the latter.
 
-7. Immutable collections.
+6. Immutable collections.
 
     Like with sequence-expressions, we believe that dictionary-expressions should be able to target types like `ImmutableDictionary<TKey, TValue>`.  Our hope is that `CollectionBuilderAttribute` can be used for this purpose, likely pointing at signatures like: `ImmutableDictionary.CreateRange<TKey, TValue>(ReadOnlySpan<KeyValuePair<TKey, TValue>> items)`.