LDM Notes for September 25th, 2023

[333fred]

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

Agenda

• Primary constructors
• Defining well-defined behavior for collection expression types

[TonyValenti]

How does the compiler know if an enumerable is side-effecting?
RE Well-behaved collections:

I have a GetConsumingEnumerable extension methods that remove items from their underlying collections. How do I mark this as side effecting?

[CyrusNajmabadi]

Strongly agree that the spec should guarantee that a spread element will only be (directly) enumerated once.

Note that I said "directly" enumerated: of course the compiler can't guarantee that a Count property won't also cause enumeration as a side effect

If we cannot actually guarantee anything, i don't see the purpose of putting in pretend guarantees. Better to be honest that we simply do not have this guarantee. In other words, no promise is better than a false promise.

Should the compiler guarantee

Compiler guarantees can be elsewhere. I have no issue with the compiler writing up a list of rules/heuristics/guardrails, it works within. But as far as the language is concerned. No. The language should either allow the code to be written or not. It's then up to the compiler ot make intelligent rules that benefit the vast majority, do not punish reasonable cases, but also potentially disregard the pathlogical.

[CyrusNajmabadi]

Note: We are planning to discuss this (and if spreads give LTR ordering wrt to their own independent enumeration) to see if we want to give any additional rules/guidance.

[En3Tho]

Consider this very silly example (I guess it can be called "insane" in context of this thread):

public class SillyCollection<T>(IEnumerable<T> Enumerable) : ICollection<T>
{
    public IEnumerator<T> GetEnumerator() => Enumerable.GetEnumerator();    
    public int Count => Enumerable.Count();
   // other stuff ...
}

If compiler implements any optimizations like for example TryGetNonEnumeratedCount() it automatically will enumerate the thing twice. I woudn't personally expect compiler to call .GetEnumerator() more that once for a given enumerable but giving a strong guarantee about enumerating thing only once is too limiting if not simply wrong.

[sab39]

If we cannot actually guarantee anything, i don't see the purpose of putting in pretend guarantees. Better to be honest that we simply do not have this guarantee. In other words, no promise is better than a false promise.

But we can guarantee something: we can guarantee that the compiler will not insert more than one enumeration of the collection. The compiler can't know that Count or some other property won't cause an enumeration as a side effect, but the programmer can know that about the type they're using.

Consider the extremely common case of enumerables created by generator methods - which I would expect account for the vast majority of non-collection enumerables. In that case it's inherently impossible for the enumerable to come with a Count property because it's guaranteed that the code of the generator won't execute until the result is being enumerated. I would personally find it not just unexpected but absolutely astonishing if the code of my generator method were executed more than once when I used it a single time in a collection expression.

Worse: if I do need a guarantee that my generator method code will only be run once, and the compiler doesn't give such a guarantee, then my only option is to insert a ToList() call or similar, which then allocates unnecessary storage and results in redundant copying. Or to use something other than collection expressions.

Worse still: if the language reserves the right for the compiler to enumerate spread elements more than once but doesn't actually do so in the initial release, it's all but certain that code will be written inadvertently relying on this fact. Which would then make it a breaking change in practice anyway if the compiler ever started doing it, even though the code was technically relying on undefined behavior in the language.

[CyrusNajmabadi]

@sab39 we're going to bring this up for discussion.

Which would then make it a breaking change in practice anyway

That's not the case. That's the point about explicitly not making promises. :)

Note: this is not hypothetical, around things like well-behavedness, we will not consider it break, since it's depending on explicitly undefined behavior.

That said, we are going to bring this up. I'm not opposed to some additional statements here if it builds some confidence for these esoteric cases.