You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Collection expressions use the iteration type of the target type for type inference, overload resolution, and verifying [CollectionBuilder] attributes. Currently, the iteration type calculation depends on the location where the collection type is used since iteration type may require looking for an extension GetEnumerator() method. That makes the calculation potentially expensive.
We should consider optimizing the calculation when possible. One possibility is to require types used for collection expressions to have an instanceGetEnumerator() method rather than allowing extension methods. Then the calculation would be independent of the use-site, and the iteration type could be cached on the TypeSymbol directly. If extension methods are allowed, we could still cache the iteration type on the TypeSymbol for the instance method cases but fall back to binding if the iteration type is not cached.
NOte: requiring instnace GetEnumerator would be weird especially as that means you could observe different behavior between foreaching something, versus collection-exprs. I'm wary of that.
Could you give a specific scenario where you feel the behavior would be strange? I personally don't feel worried because instance GetEnumerator is always better than an extension. I def think that if you are applying CollectionBuilder, it is reasonable to be implementing GetEnumerator just once, on the same type which has the attribute.
Collection expressions use the iteration type of the target type for type inference, overload resolution, and verifying
[CollectionBuilder]
attributes. Currently, the iteration type calculation depends on the location where the collection type is used since iteration type may require looking for an extensionGetEnumerator()
method. That makes the calculation potentially expensive.We should consider optimizing the calculation when possible. One possibility is to require types used for collection expressions to have an instance
GetEnumerator()
method rather than allowing extension methods. Then the calculation would be independent of the use-site, and the iteration type could be cached on theTypeSymbol
directly. If extension methods are allowed, we could still cache the iteration type on theTypeSymbol
for the instance method cases but fall back to binding if the iteration type is not cached.See #69594 (comment).
The text was updated successfully, but these errors were encountered: