LDM Notes for February 5th, 2024

[333fred]

https://github.com/dotnet/csharplang/blob/main/meetings/2024/LDM-2024-02-05.md

Agenda

• First-class span types
• Collection expressions: inline collections

[RikkiGibson]

There have been complaints that the experience of overloading on Span<T> and IEnumerable<T> is painful. When you do this, arrays are ambiguous as arguments. SharpLab.

So, I am wondering if an additional betterness rule should be added as part of the feature. For example, maybe the new language-level Span conversions should be "better" than implicit reference conversions. The exact set of which things should be better than which other things TBD.

This might be consistent on some level with a decision we made for collection-expressions, that converting a collection-expr to Span is better than converting it to IEnumerable, for example.

[Joe4evr]

#7276

[RikkiGibson]

Thanks, I forgot about this decision. It feels to me like probably making Span implement IEnumerable and then having a betterness rule around interface implementation is still going to solve this. (I don't think implicit conversion per se works, since ref structs implementing interfaces only allows them to meet interface constraints, it doesn't permit actually permit converting the ref struct value to interface type.)

[RikkiGibson]

Though, tbh, it feels like in order for Span to actually implement IEnumerable..then it needs to be able to produce an IEnumerator which enumerates the span. No idea how that would work :)

[bbarry]

We thought about whether this should extend to Memory<T>, but are wary of it. Memory<T> does not have an implicit conversion to Span<T>/ReadOnlySpan<T> because, depending on the backing storage, it can have a cost to convert, and we'd be worried about suddenly creating such conversions in the language.

Are you implying ReadOnlyMemory<T> here? I'm assuming so because Memory<T> is ref while ReadOnlyMemory<T> is readonly ref.

[333fred]

Yes, but if we were to extend the same semantics to Memory<T>, there would be an implicit conversion from a Memory<T> to a ReadOnlySpan<T>, just as there will be from Span<T> to ReadOnlySpan<T>.

[RenderMichael]

At the same time, though, we are also sympathetic to the concern that, if a code path needs to be asyncified and converted to Memory, that may necessitate more changes to allow what works for Span to work in the async world.

Has the LDM considered allowing ref structs in async methods as long as one doesn’t cross an await?

[333fred]

Yes, but there's two problems with that:

1. The cases we're talking about here are likely method parameters. That makes the conversation much more difficult, and very likely means that they'll cross a boundary.
2. While we've done this for limited scenarios (such as interpolated strings without an await inside them), the general broad feature is harder to rationalize and needs a decent amount of design work to flesh out the edges.

[RenderMichael]

Those are fair concerns in a lot of cases. Often when I have ref struct locals as opposed to parameters, it’s not too hard to refactor into a separate method.

Still, scenarios such as those best served by ValueTask, where the asynchronous path is a fallback or one of many branches, this idea would be extremely useful.

[huoyaoyuan]

Please don't forget yield method when doing this.