Collection expression arguments: open questions #9158
Conversation
| Should collection arguments and the applicable methods affect convertibility of the collection expression? | ||
|
|
||
| ```csharp | ||
| Print([with(comparer: null), 1, 2, 3]); // ambiguous or Print<int>(HashSet<int>)? | ||
| static void Print<T>(List<T> list) { ... } | ||
| static void Print<T>(HashSet<T> set) { ... } | ||
| ``` |
There was a problem hiding this comment.
Print<int>(new(comparer: null)) gives:
CS0121: The call is ambiguous between the following methods or properties: 'C.Print(List)' and 'C.Print(HashSet)'
If that's ambiguous, it would be intuitive to me for Print<int>([with(comparer: null)]) to also be ambiguous. The commonality being target-typing while providing constructor arguments.
Given that, then since the presence of items is unrelated to the differentiation between the overloads, I don't know what the motivating reason would be to make Print([with(comparer: null), 1, 2, 3]) be able to resolve the overload ambiguity.
There was a problem hiding this comment.
agreed. and i imagine the same holds true of Print<int>(new(comparer: null) { 1, 2, 3 }).
There was a problem hiding this comment.
Thanks. I've added those examples.
| public void Add(T t) { ... } | ||
| // ... | ||
| } | ||
| ``` |
There was a problem hiding this comment.
similar to above, the following is not legal today: UseMyCollection(new(1));. So i would expect the same to be true with CEs
| For either of those cases, arguments are required: | ||
| ### Collection builder parameter order | ||
|
|
||
| For *collection builder* methods, should the elements parameter be before or after any parameters for collection arguments? |
There was a problem hiding this comment.
@stephentoub for thoughts. Are there different API shapes you want CBA to be able to point to wrt the elemtns vs other arguments?
There was a problem hiding this comment.
We effectively have both orderings in the core libraries.
Collection types like Dictionary typically have a constructor that takes a collection of source elements and then a comparer, e.g.
ctor
But Create methods like these:
FrozenSet
ImmutableHashSet
have used the other order, comparer and then elements, so that the elements can be params.
To best take advantage of existing Create methods, we probably want to use the comparer-then-elements ordering (even though I don't particularly like that ordering, especially now that we have collection expressions and params isn't as valuable as it used to be).
proposals/dictionary-expressions.md
Outdated
|
|
||
| For reference, with non-dictionary targets, an element with `dynamic` type, the compiler binds to the applicable `Add(value)` method at runtime. | ||
|
|
||
| For dictionary targets, the situtation is more complicated because we have key-value pairs to consider. ... |
There was a problem hiding this comment.
... implies unfinished, but just in case:
| For dictionary targets, the situtation is more complicated because we have key-value pairs to consider. ... | |
| For dictionary targets, the situation is more complicated because we have key-value pairs to consider. ... |
There was a problem hiding this comment.
Thanks. I've since removed the question about dynamic elements and clarified the steps in the Construction section so I think the question no longer applies.
proposals/dictionary-expressions.md
Outdated
|
|
||
| For dictionary targets, the situtation is more complicated because we have key-value pairs to consider. ... | ||
|
|
||
| There is a related question of *key-value pair conversions* (see below). If we allow dynamic conversion of key or value independently, then we're essentially supporting key-value pair conversions at runtime. If that's the case, we'll probably want to key-value pair conversions at compile-time for non-`dynamic` cases. |
There was a problem hiding this comment.
| There is a related question of *key-value pair conversions* (see below). If we allow dynamic conversion of key or value independently, then we're essentially supporting key-value pair conversions at runtime. If that's the case, we'll probably want to key-value pair conversions at compile-time for non-`dynamic` cases. | |
| There is a related question of *key-value pair conversions* (see below). If we allow dynamic conversion of key or value independently, then we're essentially supporting key-value pair conversions at runtime. If that's the case, we'll probably want to do key-value pair conversions at compile-time for non-`dynamic` cases. |
cston
force-pushed
the
collection-args-questions
branch
from
fbe0718 to
0d5e1f2
Compare
No description provided.