LDM Notes for May 3rd, 2023

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-05-03.md

Agenda

• Inline Arrays
• Primary constructors
  • Attributes on captured parameters
  • Warning for shadowing base members
• Collection literal natural type

[TahirAhmadov]

Regarding collection literal natural type, there are two important points that were already discussed in the main issue:

• Immutable collections are not very useful in the scenario where a natural type is needed at all, specifically - var locals. Why else would you assign a collection to a local, other than to modify it? Yes, in some cases the same collection can be passed as an argument to multiple method calls, which would save allocations, but those methods expect a specific parameter type, so it's to be expected var is frequently not usable at all for this.
• The foreach scenario is not the same as var and is more like IEnumerable<T>. And for that... Per further discussion, it's a special use case entirely, and can be lowered to something even faster than an array with IEnumerable<>.
• For IEnumerable<T>, arrays should be used, IMO. The only promise is enumerability, and arrays satisfy that, and are cheaper than List<T>.
• Arrays already have a somewhat easier syntax - SomeType[] x = [a, b, c]; - which is shorter than List<SomeType> x = [a, b, c]; so I think it would be counter-productive to make var also do arrays, while leave List<> out in the cold.

Basically, I think List<T> is the best candidate, having considered all of the above.

[alrz]

So assuming list as the natural type, would this be ambiguous,

void M(T[])
void M(Span<T>)

while this is not?

void M(T[])
void M(List<T>)

[TahirAhmadov]

What about generic inference like List<_> x = ["a", "b"];

[CyrusNajmabadi]

So assuming list as the natural type, would this be ambiguous,

No. Those don't involve a natural type. Those are target types. And we would certainly both want this to work, and pick the "better" overload. Note that we already established this in the params span working group. Since params Span<T> is better than params T[], the same would certainly hold for collection literals.

void M(T[])
void M(List<T>)

Also not a natural type situation. :)

IMO, we should have a betterness path that has this order:

1. spans. least overhead, can often be on the stack if small enough.
2. arrays. minimal overhead, but on heap.
3. constructible type (open question if Collection-Initialize or Construct-form have any priority between themselves). These produce concrete types, thus producing something which can have lower overhead to use (ops are normally non virtual, and iterating is often no overhead).
4. interface types. These tend to be the least desirable. All ops on them are virtual. Iterating incurs allocations.

[CyrusNajmabadi]

What about generic inference like List<_> x = ["a", "b"];

That would be a different feature (inferring generic args). If we ever do that feature, i would expect it to work with collection literals.

[alrz]

we should have a betterness path that has this order

I missed the change at #7171, I guess that's exactly what you described?