The proposal fixes LazyFilterSequence-to-Array conversion that calls
predicate twice for each element.
What do you think?
- Anton
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.
···
on Sun Jun 19 2016, Kevin Lundberg <swift-evolution@swift.org> wrote:
this seems more like a bug fix to me than a language change. Does it
need to go through evolution?
--
-Dave
this seems more like a bug fix to me than a language change. Does it
need to go through evolution?
···
On 6/19/2016 7:43 AM, Антон Жилин via swift-evolution wrote:
The proposal fixes LazyFilterSequence-to-Array conversion that calls
predicate twice for each element.What do you think?
- Anton
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I think I agree that it’s a bug; as stated in the proposal the current behaviour allows .underestimatedCount to consume the entire sequence 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.
···
On 19 Jun 2016, at 14:50, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Sun Jun 19 2016, Kevin Lundberg <swift-evolution@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.
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.
···
on Sun Jun 19 2016, Haravikk <swift-evolution@swift.org> wrote:
On 19 Jun 2016, at 14:50, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
on Sun Jun 19 2016, Kevin Lundberg <swift-evolution@swift.org> wrote:
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