Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-6999] Changed return type of lazy.prefix(through:).filter() from Swift 4.0 to 4.1 #49547

Open
Lukasa opened this issue Feb 14, 2018 · 7 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella

Comments

@Lukasa
Copy link
Contributor

Lukasa commented Feb 14, 2018

Previous ID SR-6999
Radar None
Original Reporter @Lukasa
Type Bug
Additional Detail from JIRA
Votes 0
Component/s Standard Library
Labels Bug
Assignee None
Priority Medium

md5: 0c9f78c22e57cb25e86de2a1304d694e

Issue Description:

Consider the following program:

class LazyHundredCollection: Collection {
    var startIndex = 0
    var endIndex = 100

    subscript(_ idx: Int) -> Int {
        return idx
    }

    func index(after i: Int) -> Int {
        return i + 1
    }
}

let coll = LazyHundredCollection()
let result = coll.lazy.prefix(through: 50).filter { $0 % 2 == 0 }
print(result.self)

On the released Swift 4.0.2, this is the printed result:

[0, 2, 4, 6, 8, 10, 12, 14, 16, 18, 20, 22, 24, 26, 28, 30, 32, 34, 36, 38, 40, 42, 44, 46, 48, 50]

However, on the Swift 4.1 2018-02-13a snapshot, the printed result is:

LazyFilterCollection<Slice<LazyCollection<LazyHundredCollection>>>(_base: Swift.Slice<Swift.LazyCollection<__lldb_expr_1.LazyHundredCollection>>(_startIndex: 0, _endIndex: 51, _base: Swift.LazyCollection<__lldb_expr_1.LazyHundredCollection>(_base: __lldb_expr_1.LazyHundredCollection)), _predicate: (Function))

This represents a change in return type, from Array<Int> to LazyFilterCollection<Slice<LazyCollection<LazyHundredCollection>>>. While I appreciate that this potentially (I say "potentially" because of SR-6991) fixes the above misbehaviour of non-lazily iterating the collection, this is a source breaking change and presumably should be delayed to Swift 5.

@belkadan
Copy link
Contributor

Changing behavior does not make something "source-breaking", but it's true that someone could have been relying on string conversion for the result of this operation.

@airspeedswift?

@Lukasa
Copy link
Contributor Author

Lukasa commented Feb 14, 2018

Ignore the string conversion; that was just to visually show the problem. The actual return type is different.

@Lukasa
Copy link
Contributor Author

Lukasa commented Feb 14, 2018

Put another way: the bug is not in the print statement, it’s in the fact that the type of the argument to print is different on different versions.

@airspeedswift
Copy link
Member

I would probably put this in the "additive overloading features can break source by shadowing but we don't consider them source breaking" column. Note you can get the original behavior via type context i.e.

let a: Array = coll.lazy.prefix(through: 50).filter { $0 % 2 == 0 }

@belkadan
Copy link
Contributor

Right. It's only a bug because of the string conversion, or rather the conversion to Any. In most other cases it will "just work" (either use in an Array context, or use as a general Collection); with a few rare cases you'd get a static type error.

@Lukasa
Copy link
Contributor Author

Lukasa commented Feb 15, 2018

Ah cool, I see what you're getting at. So just to clarify, this is not considered a breaking change if the new type can be fixed up by the compiler to get the old one instead?

@airspeedswift
Copy link
Member

The compiler isn't fixing anything. The old function, that produced an array, is still there. The type context just ensures that one gets called instead of the newer, more-specific, overload.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. standard library Area: Standard library umbrella
Projects
None yet
Development

No branches or pull requests

3 participants