kean / future Goto Github PK

I pulled 0.4.0 after you tagged it and included it into a project, noticing almost immediately after that you'd updated the platforms designator in Package.swift to be some of the more recent ones.

I'm not sure if that was explicitly intentional, and you didn't want to support older versions with this library and release version, which is the implication. You may already know this, but the platform segment of Package.swift provides the "minimum level" of API by platform that is to be supported by the code, roughly equivalent and related to the @available() macro that's used to indicate specific APIs aren't available before a given point.

In practice, this means that anyone relying on Future with this version (0.4.0) can't link to generate targets earlier than macOS 10.13, iOS & tvOS 11, etc. I didn't see any of those specific changes in the recent updates, so I think these could easily be older versions without any ill effect.

I understand this is your library and you want to be clear about expectations around "supported" versions, as such it's clearly your call - but I'd like to encourage you to consider being as conservative as possible with updating those values, as it promotes constraints external to this library on anyone using it that may not be needed.

Similar to the Swift NIO EventLoopFuture implementation, it would be nice to be able to do something like this:

let someFuture: Future<Data, Error> ...
someFuture.map { someData -> SomeCodableObject in 
    let decoder = JSONDecoder()
    return try decoder.decode(SomeCodableObject.self, someData)
}

This would also apply to flatMap and the other operators of course.

Although it would probably break the typed error functionalities.

I was looking around at promise style libraries to help solve a problem in another project, and wanted to utilize this library. It's pretty close, but doesn't currently easily (and consistently) support swift on linux out of the box. I'm willing to make some tweaks and updates to enable that, but wanted to inquire first if that would be acceptable.

I've offered a partial (small) update to Package.swift in #10 - but I'd like to take it a bit further based on my initial exploration:

• update the tests to push them slightly lower (into a subdirectory) to more easily exclude the Host IOS app
• add swift test to macOS command line to validate that continues to work as expected (not just through xcodebuild)
• add linux focused CI running the tests (in either .travis or .github actions, if you have a preference)
• replace the arc4random usage in the test extensions with a more platform neutral https://developer.apple.com/documentation/swift/randomnumbergenerator