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
Since the only two shuffle methods are defined on AbstractArray, it seems like it would be handy to have a fallback definition for shuffle that first collects the iterator, like
shuffle(itr) =shuffle(collect(itr))
Maybe I've overlooked a reason why this shouldn't be implemented?
The text was updated successfully, but these errors were encountered:
Maybe I've overlooked a reason why this shouldn't be implemented?
Should all methods that work on arrays have a fallback that calls collect? Personally, I think it is clear and straightforward that if you have an iterator and want to call a method only working on arrays, then you collect and call the method. Makes it explicit what is going on and that you actually have to allocate the array up front instead of hiding that.
Yeah, that makes sense. I was thinking that it seems reasonable to shuffle an iterator, but I guess a more precise way to phrase the litmus test for whether foo should work on iterators (as opposed to my "seems reasonable" litmus test) is something like this:
Is it possible to write a foo(itr) method that returns an iterator?
If not, then there shouldn't be a fallback foo(itr) = foo(collect(itr)) method. And I suppose it's not possible to have shuffle return an iterator. 😅
Currently,
shuffle
does not work on iterators:Since the only two
shuffle
methods are defined onAbstractArray
, it seems like it would be handy to have a fallback definition forshuffle
that first collects the iterator, likeMaybe I've overlooked a reason why this shouldn't be implemented?
The text was updated successfully, but these errors were encountered: