[swift-evolution] [Proposal] Fix lazy filter

[Dave Abrahams]

on Sun Jun 19 2016, Haravikk <swift-evolution at swift.org> wrote:

>> On 19 Jun 2016, at 14:50, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Sun Jun 19 2016, Kevin Lundberg <swift-evolution at swift.org> wrote:
>> 
>>> this seems more like a bug fix to me than a language change. Does it
>>> need to go through evolution?
>> 
>> It's not a bug.  Measuring the length of the source before allocating
>> the destination array is usually a big win when compared to repeatedly
>> growing the array's memory and copying all its elements.
>
> I think I agree that it’s a bug; as stated in the proposal the current
> behaviour allows .underestimatedCount to consume the entire sequence

If that's true, it's a documentation bug.  underestimatedCount is
supposed to be a nondestructive estimate of the sequence's length, and
if the sequence is not known to be multipass, it always returns 0.

> because sequences are potentially destructive (so its only possible to
> guarantee access to each element once). Actually, the fact that this
> hasn’t been discovered sooner suggests the current tests don’t include
> the use of destructive sequences, which may need to be considered too,
> as all Sequence methods should work correctly with both destructive
> and non-destructive sequences.
>
> So yeah, I think having lazy sequences of this type return 0 for
> underestimateCount is the right solution for the time being.

-- 
-Dave