slazyk / sinq Goto Github PK

Hi,

Thanks for providing this valuable library.

I've tried using SINQ in an Xcode6-Beta5 playground, but find that all but .toArray() cause the playground to lock up. Could anyone confirm?

Daniel

CocoaPods 0.36 is now out of beta & rc and the official 0.36.0 version with Swift & Framework support has been released 2 days ago.

(Don't forget to consult the guides and CocoaPods blog if you need help, we recently added a "guide for pod authors" dedicated for Swift pods)

Compiling the library under Xcode 7.3 (Beta 5) gives the following error:

SINQ.swift:27:20: Cannot invoke initializer for type 'AnySequence<>' with an argument list of type '(S)'
SINQ.swift:27:20: Overloads for 'AnySequence<>' exist with these partially matching parameter lists: (S), (() -> G)

Given the iOS 9.3 release is days away this should probably be fixed immediately as apps using SINQ will start to break

In Swift Beta 4 Apple added lazy() and LazySequence, LazyBidirectionalCollection, LazyForwardCollection and LazyRandomAccessCollection which seem similar in purpose to what sinq() and SinqSequence are.

The new lazy types provide lazy chainable .map .filter .reverse .array and subscript.

sinq(1...100).filter{ $0 % 2 == 0 }.map{ %0 % 3 } // me
lazy(1...100).filter{ $0 % 2 == 0 }.map{ %0 % 3 } // apple

It might be a good idea to refactor SINQ so it extends those types. Or at least maybe borrow from them the design of splitting into specialised cases for: sequences, {forward, bidirectional, random access} collections.

As of Beta 4 some functions that were lazy are now eager, notably Swift.map and Swift.filter. Their use should be removed from the implementation.

...but they also added lazy(), which can be used as follows

lazy(1...100).filter{ $0 % 2 == 0 }.map{ %0 % 3 }

looks familiar :) ?

sinq(1...100).filter{ $0 % 2 == 0 }.map{ %0 % 3 }

Any ETA on support for Swift 2.3/3.0?

Right now when you include the pod you have to go through a manual conversion process of the code to the new syntax. If code-level breakages are a must perhaps we could keep a separate branch for the Swift 2.2 codebase and move the new one to 2.3/3.0.