LDM notes for August 9, 2023

[MadsTorgersen]

https://github.com/dotnet/csharplang/blob/main/meetings/2023/LDM-2023-08-09.md

Agenda

• Lambdas with explicit return types
• Target typing of collection expressions to core interfaces
• Loosening requirements for collection builder methods

[TonyValenti]

If it is not already enabled, it would be great if interfaces could also be tagged with the collection builder attribute.

[CyrusNajmabadi]

They can be @TonyValenti . This is how types like IImutableList<T> work with this feature.

[sab39]

The current C#12 proposal, as I understand it, is that collection expressions have no natural type. Does that mean that they won't work with foreach out of the box? That would be pretty disappointing, if so, considering that while we may not know the collection type, we do know the iteration type, and so we know exactly what foreach should do, for any well-behaved collection type.

Further, since the actual collection can't be observed, the compiler doesn't need to pick or even use a collection type at all - it could optimize

foreach (var num in [1, 2, 3])
{
  func(num);
}

by unrolling it directly into

func(1);
func(2);
func(3);

Am I right that without a natural type we don't get foreach for free? If so, I propose that a special case rule be added to permit collection expressions in foreach regardless, because IMO it would be very surprising and frustrating to users if that didn't work.

[sab39]

We are discussing ways to make them work with foreach without a natural type. for example by target-typing them to ReadOnlySpan<ForeachElementType>.

Also, ReadOnlySpan<> wouldn't be optimal in all cases - particularly unknown-length literals. Consider

foreach (var i in [..Enumerable.Range(1, 1000), ..Enumerable.Range(2000, 3000)])

Seems like it would be better to leave the compiler flexibility about what type to pick rather than specifying something concrete. In much the same way as target-typing to IEnumerable<T> guarantees you'll get a type that implements that interface but allows the compiler complete freedom in what specific type to use, foreach could guarantee you'll get something that (behaves as if it) implements the pattern of methods foreach expects, but leave it up to the compiler what the actual type is.

[CyrusNajmabadi]

Also, ReadOnlySpan<> wouldn't be optimal in all cases - particularly unknown-length literals. Consider

Target-typign has no relation to what is emitted. It just means how we determine applicability/conversions. The actual emit logic can be optimized however we feel is appropriate based on input types.

[AartBluestoke]

"Target-typing has no relation to what is emitted."

is it possible that knowing that the current implicit list is being compiled for a foreach (var i in [true,false])
could produce different output to a call foo([true,false]) despite the same implicit list? - having the context in which the implicit list appear (ie the type it is targeted against) influence what the compiler does?

and would such things be a matter for the language, or just an implementation detail?

[CyrusNajmabadi]

@AartBluestoke sorry, i'm not quite sure what your question is. Can you clarify? Thanks!

[CyrusNajmabadi]

having the context in which the implicit list appear (ie the type it is targeted against) influence what the compiler does?

Absolutely. The target very much will affect what the compiler does.

and would such things be a matter for the language, or just an implementation detail?

The language determines what is legal and what semantics something has. The compiler is free to implement things how it wants as long as what it does isn't observably different from the required semantics.