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
I have found the collection very useful in all sorts of places, most recently in a custom event-subscription system. For that I may want to enumerate the list in reverse, which can be done almost trivially by adding another Enumerator.
While the current enumerator also enumerates items that are added during enumeration, this new one would not, but that seems a minor issue, or maybe even desired behaviour.
The list could keep a no-data object internally which is returned with this property and implements GetEnumerator() correctly. While a bit of a shame in terms of memory, this will make sure there is no unnecessary pressure on the GC.
The text was updated successfully, but these errors were encountered:
Note that LINQ has a Reverse(), but my assumption is that this will first enumerate to list (or something similar), and then loop backwards, so that will work just fine already, it will just not skip if you delete an object before reaching it. In that case, Reverse() doesn't seem very useful. [/random]
I have found the collection very useful in all sorts of places, most recently in a custom event-subscription system. For that I may want to enumerate the list in reverse, which can be done almost trivially by adding another Enumerator.
While the current enumerator also enumerates items that are added during enumeration, this new one would not, but that seems a minor issue, or maybe even desired behaviour.
I propose adding the following property:
The list could keep a no-data object internally which is returned with this property and implements GetEnumerator() correctly. While a bit of a shame in terms of memory, this will make sure there is no unnecessary pressure on the GC.
The text was updated successfully, but these errors were encountered: