Open swift-ci opened 7 years ago
cc @airspeedswift, @moiseev
This, unfortunately, is not the only case where one can accidentally lose laziness. Something can probably be done to address these problems when we get conditional conformances (at the very least .lazy will be touched once the conditional conformances exist, so it makes sense to perform this work at the same time).
Thanks dennisvennink (JIRA User) for pointing this out.
Comment by Dennis Vennink (JIRA)
CC: @airspeedswift, @moiseev
What's the status of this bug? (Since conditional conformances have landed?)
Should have been fixed, actually.
Just tried it in Xcode Version 9.4.1 and [1,2,3].lazy.prefix(2)
returns a Slice<LazyCollection<Array<Int>>>
, so the operations chained after that should all be lazy.
Please verify.
Comment by Dennis Vennink (JIRA)
While [1,2,3].lazy.prefix(2)
does indeed return
a Slice<LazyCollection<Array<Int>>>
here in 10.0 beta (10L176w), the reported bug, in which prefix(_: )
doesn't have an overload for types conforming to LazySequenceProtocol
s, is not fixed.
Come to think of it, it's probably not implemented yet, which makes this more of a feature request.
Another example:
print(type(of: sequence(first: 0, next: { $0 + 1 }).lazy.prefix(10)))
// AnySequence<Int>
(As an aside, the Standard Library already defines a lazily implemented internal
type called _PrefixSequence
.)
Comment by Dennis Vennink (JIRA)
Incorrectly submitted as a bug.
What is the type you suggest the prefix(_: )
should return when applied to a LazySequenceProtocol
?
Comment by Dennis Vennink (JIRA)
The least obtrusive and elegant solution would be a new type called LazyPrefixSequence
that conforms to LazySequenceProtocol
. This would probably also require a LazyPrefixCollection
conforming to LazyCollectionProtocol
.
(I could write an Evolution proposal, if it requires one.)
This is opening a can of worms, unfortunately. If we take this approach, it would have to be replicated for other methods like dropFirst(_ : )
and suffix(_: )
.
/cc @airspeedswift
I'm encountering this in relation to an UnfoldSequence, as
if let i = (sequence.lazy.compactMap{$0}.first)
If I say that, I lose laziness. I can work around the issue by saying
if let i = (sequence.lazy.compactMap{$0}.first{_ in true})
because first(where:)
preserves laziness while first
does not. That seems a little nutty.
(I believe I'm right in adding this as a comment here, but if should be filed as an actual separate bug, please tell me and I'll do that.)
Additional Detail from JIRA
| | | |------------------|-----------------| |Votes | 1 | |Component/s | Standard Library | |Labels | Improvement, swift-evolution-proposal-needed | |Assignee | dennisvennink (JIRA) | |Priority | Medium | md5: e849cf83ebd7f75ce734f35ceabb20c9Issue Description:
prefix(_ maxLength:)
returns anAnySequence
when operating on an object that conforms toLazySequenceProtocol
making subsequent operations eager. I know we can add another call to lazy afterprefix
to get back into lazy land, but that kind of defeats the entire purpose of thelazy
property; once we're lazy we should stay lazy.Thoughts?