LDM Notes for September 11th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-09-11.md

Agenda

• Better conversion from collection expression and params collections
• First-class span types
  • Reverse
  • New ambiguities
  • Covariant arrays

[huoyaoyuan]

I was hitting Reverse with covariant in dotnet/runtime#105407 , but not overload resolution case.

In-place Reverse as well as Shuffle are quite special operations. They require writable destination, but are tolerate with covariance because all written items come from the original storage. I'm not sure whether it's actionable to make improvements here.

[KennethHoff]

( on betterness changes):

we want to make the rules for the new feature consistent with the new rules for the old feature.

Is this a typo? Shouldn't it be "consistent with the rules for the old feature." (i.e. not "new rules for old feature")

[333fred]

Nope. The new rules for the old feature is params collections. Ie, all 3 (collection expressions, params arrays, params collections) are now as consistent as we can can make them.

[KennethHoff]

but params collections aren't an old feature?

Params arrays are old, are they changing too?

Collections collections are arguably old - and they are changing (?) - is this the argument?

[333fred]

but params collections aren't an old feature?

They're new rules on an old feature.

[KennethHoff]

Ah, so params arrays and the new params collections are the same feature in the LDM's eyes? Fair enough 👍🏻

[tfenise]

I would argue the conversion T[] -> Span<T> should not be automatically preferred over T[] -> IEnumerable<T>(or more generally, IReadOnly*<T>) at all, because a method with a Span<T> parameter may modify the span (otherwise it should just accept ReadOnlySpan<T>), but a method with an IEnumerable<T> parameter probably never modifies the collection, so the semantics of such two methods are probably different even if they have the same name, and one of them should not be automatically preferred over the other.

I am also curious why a rule of "Better conversion from expression" is proposed to be introduced, instead of a rule of "Better conversion target" to prefer (ReadOnly)Span<T> over I(ReadOnly)*<T>, etc. Unconditionally preferring implicit span conversions over implicit conversions that are not implicit span conversions sounds inappropriate. Why should T[] -> Span<T> be preferred over T[] -> ArraySegment<T>? T[] -> ArraySegment<T> sounds better.

[333fred]

Again, Span should be preferred over ArraySegment in the sense of API design does not mean Span should be preferred over ArraySegment in the sense of overload resolution.

I still disagree with this statement. API design absolutely needs to take overload resolution into account, and I've said several times, the future of .NET is in Spans, not ArraySegments.

[tfenise]

There is another problem with the proposed rule that implicit span conversions be always preferred in any case, which is that it does not resolve the ambiguity between ArraySegment<T> -> Span<T> and ArraySegment<T> -> IList<T>. ArraySegment<T> -> Span<T> is just a user-defined implicit conversion, not an implicit span conversion provided by the language, so the proposed rule does not help. Instead, the potential rule that Span<T> be better conversion target than IList<T> would cover this case.

I am not saying that the whole first-class Span types proposal should take user-defined types like ArraySegment<T> into account. That would be too complicated. However, the potential rule that (ReadOnly)Span<T> be better conversion target than I(ReadOnly)*<T> is no more complicated than the proposed rule that implicit span conversions be always preferred in any case, and resolves more ambiguities, so it is more desirable.

[tfenise]

There is even another problem with the proposed rule that implicit span conversions be always preferred in any case, which is that it prefers DerivedClass[] -> ReadOnlySpan<BaseClass> over DerivedClass[] -> IEnumerable<DerivedClass>. Arguably, there should be an ambiguity between DerivedClass[] -> ReadOnlySpan<BaseClass> and DerivedClass[] -> IEnumerable<DerivedClass>, as there is an ambiguity between DerivedClass[] -> IReadOnlyList<BaseClass> and DerivedClass[] -> IEnumerable<DerivedClass>.

[CyrusNajmabadi]

These don't seem like problems to me. We discussed what should happen in cases like this and were happy with the direction.

[jaredpar]

I've said several times, the future of .NET is in Spans, not ArraySegments.

The present of .NET is Spans. 😄