Skip to content

Conversation

stephentoub
Copy link
Member

LINQ operators are lazy and can't factor in the current contents of a mutable list when making decisions about how to subsequently process that list. The optimizations in dotnet/corefx#36051 and dotnet/corefx#41342 violated that and broke TakeLast and SkipLast when the underlying source changes after calling Take/SkipLast and before calling GetEnumerator.

Fixes #39864

LINQ operators are lazy and can't factor in the current contents of a mutable list when making decisions about how to subsequently process that list.
@ghost
Copy link

ghost commented Sep 20, 2020

Tagging subscribers to this area: @eiriktsarpalis, @jeffhandley
See info in area-owners.md if you want to be subscribed.

@eiriktsarpalis
Copy link
Member

Looks good to me, but wouldn't it in principle be possible to preserve the existing optimization by delaying it to enumerator initialization time? Granted, this might require nontrivial refactoring of the existing implementation.

@stephentoub
Copy link
Member Author

this might require nontrivial refactoring of the existing implementation

Right. That's a separate feature. The faulty optimization is being reverted here, and if someone wants to try again separately and validate it's useful, that's welcome.

@stephentoub stephentoub merged commit cb48c82 into dotnet:master Sep 21, 2020
@stephentoub stephentoub deleted the fixtakeskip branch September 21, 2020 13:48
timandy added a commit to timandy/linq that referenced this pull request Oct 6, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 7, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

IEnumerable<T>.SkipLast and TakeLast behave wrong
3 participants