on Sun Jun 19 2016, Haravikk <[email protected]> wrote: >> On 19 Jun 2016, at 14:50, Dave Abrahams via swift-evolution >> <[email protected]> wrote: >> >> >> on Sun Jun 19 2016, Kevin Lundberg <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
