A problem of the may-actually-be-worse-in-my-head-than-in-reality variety, but Deferred.Task shadows Foundation.Task. Any generics misuses or error involving Task tends to instead error about misuse of the Foundation type instead.

Installation fails with:

[!] Unable to satisfy the following requirements:

- `BNRDeferred (= 3.0.0-beta.1)` required by `BSWFoundation (0.2.0)`

None of your spec sources contain a spec satisfying the dependency: `BNRDeferred (= 3.0.0-beta.1)`.

read-write vs read-only

Bikeshed time. See also #20, #21, and #66.

Are you a BNR person assigned to this issue? You've been assigned for review! You don't need to do anything other than read through this issue and leave feedback.

This document refers to the Swift 3-style name of types unless explicitly referring to the old API.

Proposed changes

From what I can suss out in OCaml-ese, our any(_:) is correct. But is it useful? When are you going to unpack the outer Deferred and not need the innermost one immediately?

Right now, binding different Deferred<Result<T>> is very cumbersome and requires calls to bind and resultToDeferred.

For example, parsing a struct Product from a JSON might involve code like this:

    public func fetchData(url : NSURL) -> Deferred<Result<NSData>>
    public func productFromData(data : NSData) -> Deferred<Result<Product>>

    public func sampleRequest () -> Deferred<Result<Product>> {
        let someURL = NSURL()
        return fetchData(someURL).bind({resultToDeferred($0, productFromData)})
    }

If instead we would make Deferred hold a Result instead of a generic T, we could write a custom operator allowing us to make code like above a lot more readable, like this:

    public func sampleRequest () -> Deferred<Result<Product>> {
        let someURL = NSURL()
        return fetchData(someURL) |=> productFromData
    }

Is this something you will consider as an improvement?

See https://github.com/Carthage/Carthage/#tag-stable-releases.

See realm/jazzy#437, the ReSwift docs, and #84.

Custom document support seems like the best way to get things like Freddy's wiki into the Deferred documentation set (which I consider, or would like to consider, to be the canonical ground truth on Deferred.)

Alternatively, we just pull what's in the README, throw it in the GitHub Wiki, and link to it from the README. Either way.

Swift has, uh, issues with Optional<Optional<T>>. This needs a test to see.

flatMap is a generic term that's great for people who can come at this from that level already, but does a disservice to people whose first exposure to something like this is Deferred. Providing a more deferred-specific API with a more suggestive name alongside flatMap would hopefully allow them to ramp up to understanding flatMap in this context.

Suggestions:

• andEventually
• eventually
• whenResolved
• andThen

The tricky part to me is that these all could just as well be read as aliases for map, since the difference between map and flatMap comes down to map returning a Deferred<Value> that's been resolved from the get-go, while flatMap allows you to return any flavor of Deferred<Value>.

This is a tracking ticket for improvements related to multi-platform support.

• #if os-out use of NSProgress
• Set up CI

See here and here. Just one upon(queue:function:) will not leak the defaultQueue implementation detail.

Use os_unfair_lock_t? Remove the thin locks entirely? Remove ReadWriteLock entirely?

This is a tracking issue for what I imagine to be several PRs. Work is ongoing at branch zwaldowski/task and bignerdranch/Task. Vomiting my plan out on the page because I'm taking vacation. 😎 🚢

Deferred is very often used to express the result of operations that can naturally fail, expressed rationally as Deferred<Result<T>>. Deferred should include extensions to make this easier.

• Add an extremely barebones Result and ResultType.
  • Full test coverage.
• Subtree merge a cleaned up version of the work at bignerdranch/Task (private repo).
• Tree-filter to move Task/**/*.swift to Sources/Task.
• Tree-filter to move Task/TaskTests/**/*.swift to Tests.
• Implement (or finish implementing) Result primitives as FutureType where Value: ResultType extensions.
  • uponSuccess and uponFailure
  • map and flatMap overloads (or mapSuccess and flatMapSuccess)
    • Should flatMap versions throw instead of returning Result?
  • recover and recoverWith (or mapFailure and flatMapFailure)
  • async convenience initializers (init(_: () -> T), init(_: () throws -> T) for Result versions)
  • flatten
• Eating our vegetables.
  • Documentation coverage for new code.
  • As-high-as-possible test coverage.

Hello,

Sorry to bug again, but I'm finding another crash when (attempting) to observe the progress of a task. I created a gist that again reproduces the crash.

Thanks for your time and I can't thank you enough for your work on this library!

As mentioned in #78:

@jeremy-w: This README might have reached the point where a Table of Contents is appropriate. I generally use doctoc for that (npm -g install tocdoc).

And:

@zwaldowski: @jeremy-w To that point, the TOC'ed and usage-based readme should probably be transcluded in Jazzy, as if it were the "Deferred Type Programming Guide" (as long as we're going for Apple-like).

And:

@zwaldowski: Totally outside the scope of this PR, but just for reference I had in mind what ReSwift does — it's sort of the poster child for Jazzy. Notice that they split up their README into different Markdown documents that get used in the documentation set.

With SE-0116, we can perhaps use as AnyObject to treat everything as object-pointer-sized.

Hello,

In the Readme it's specified that the project doesn't support CocoaPods but the repository contains a .podspec file. When trying to install it with pod 'Deferred', another pod with the same name is installed. Do you have any idea about what's going on?

Thanks a lot!

• Swift 2.0 Travis CI
  • swift-2_0 branch protection
  • swift-2_0 branch require status checks
• Swift 1.2 Travis CI
  • master branch protection
  • master branch require status checks
• Turn off per-push builds for Travis (PR builds only)

The original Deferred describes unit and all_unit, which produce Deferred<Void>. This has been useful in our own apps and for derived types.

A simple implementation could be no different from:

deferred.map { _ in }

However, there might be some optimization that could be made in the GCD implementation (#13) by reusing the queue and block or refusing to create storage. Some effort would ideally be made to prevent that derived Deferred from being filled at all.

"Fill" suggests a "box" viewpoint. This doesn't mesh well with the "not-yet-determined value" semantic POV.

Suggestions:

• determine
• resolve
• fix
• now
• settle

Splitting into Promise/Future means that we want a term more in line with the "promise" concept. Suggestions:

• resolve (used by the pasteboard APIs)
• fulfill (suggested by @lyricsboy and keeps the 'fill' feel without committing to a box concept)
• deliver

When Deferred 3.0b1 is installed using Cocoapods and performing an Archive, the compiler throws a segmentation fault

You can find a project that reproduces this error here: YoYo

Hey guys!

I'm experiencing a crash on allSucceded where it's crashing on calling adoptChild(_:orphaned:pendingCount:) on NSProgress. The exception states that the reason is: NSProgress 0x60000032fbe0 was already the child of another progress 0x60800032abe0'

I can reproduce it 100% of the time on my code but I couldn't make it crash using a simpler project.

See current upload from Swift 3 branch.

From WWDC 2015 Session 212:

Deferred currently uses dispatch_group_wait and dispatch_async for chaining, which can exclude participation in QoS propagation and contribute to priority inversion issues. Use of the dispatch_block APIs should be investigated for Deferred chaining.

The doc comments should be updated and expanded for new users.

We can publish a nicely formatted docset as a github pages site associated with this repo.

The Future Collection extensions do not follow the Swift conventions for computed properties. In the spirit of the stdlib, getters that aren't idempotent nor O(1) should be documented as such and ideally be methods. Examples in the stdlib include generate(), popFirst(), and underestimatedCount(). Since earliestFilled and joinedValues are both O(n) in terms of the receiving collection and have threading implications, they very much fall under the "performs a calculation" rule of thumb for being methods.

This is a "gotcha" in the API for now. It's common to have multiple producers for a deferred value (say, both a network operation AND possibly the user smacking a cancel button); having to remember to do fillIfUnfulfilled or risk exploding is a wart from my point of view.

The following test demonstrates the issue (should be added to ExistentialFutureTests):

func testFill() {
    let deferred = Deferred<Int>()
    anyFuture = Future(deferred)
    XCTAssertFalse(anyFuture.isFilled)               // pass
    deferred.fill(42)
    XCTAssertNotNil(anyFuture.peek())                // fail
    XCTAssertTrue(anyFuture.isFilled)                // fail
    XCTAssertNotNil(anyFuture.wait(.Now))            // fail
    XCTAssertNotNil(anyFuture.wait(.Interval(0.1)))  // pass
}

The problem can also be observed on a pure Deferred (not wrapped in Future).

In Deferred.wait, it appears that dispatch_block_wait() returns timeout/error when called with a timeout of zero/now, as the "upon" block (which assigns value = $0) is only queued and has't completed.

Hi there

Have you try to build on Xcode 8.1 ? I have no problem running tests on the repository using Xcode 8.1 but when using the pods I run into this compilation error.

Downloading the tip of the Swift 3 branch and compiling the framework using the default scheme on release mode fails with this error:

Many of us have said the blocking value getter "only" exists for the unit tests. With the advent of @testable in Swift 2, does this mean we can/could/should mark the method as internal?

The legacy docs.md contains some high-level documentation and usage examples. The high-level stuff should be pulled into the README (if there is any mismatch; the README is already comprehensive). The usage examples should be moved into the HeaderDoc.

It looks like 3.0.0-beta.1 added Fixtures.swift to the files to be compiled with the module, which makes compilation brake when building for iOS using Cocoapods. Screenshot here

This is due to the fact that this file (that imports XCTest, which is not allowed on non-test targets) is now on Sources/TestSupport, so the podspec picks this file up for compiling the module, since it's in the Sources directory.

Let me know if you need any more info on this

This issue seeks to resurrect #75 with a limited scope, deciding on a canonical name for lazyMap and using it to replace IgnoringFuture and IgnoringTask.

I think the name would be more suggestive of the semantics if Deferred were named Eventually.

If we separate the future value from the ability to fill it, we'd likely have an internal Deferred with public "faces" Eventually<Value> and Resolve<Value>. I'm not sold on the Resolve bit – Determine, Fix, Produce, Supply. Resolve has the advantage that you can resolve.to(v), though.

Deferred preferred interface is through Future and Promise Types. We should update the README to point people toward this usage and appropriate documentation.

Short version: Future and Promise split the 2 sides of the Deferred API. Future is read-only, Promise is write-only. So you make a Deferred, ensure the Promise view has only one owner, and give the Future out to anyone that wants it.

Instead of withReadLock<Return>(@noescape body: Value -> Return) -> Return, we should have withReadLock<Return>(@noescape body: Value -> throws Return) rethrows -> Return so you can throw across lock boundaries. Same with withWriteLock.

Looking to get 👍 or 👎 on dc59e5b.

See also #101.

Should replace toInt() with Int's failable initializer.

I cannot recreate it on a smaller project. But I'm getting consistent crashes on latest commit of the Swift 3 branch. The backtrace looks like this:

The logger says:

_TtC8DeferredP33_9528CFABF28443747CE301F7DAD432BB13ProxyProgress object 0x127c17fa0 overreleased while already deallocating; break on objc_overrelease_during_dealloc_error to debug

Building for ARM64 in DEBUG. Please let me know if there is a way to help debug this, and as always: THANKS!

Discourage the use of IgnoringFuture's initializer, preferring for the type itself to go away in the future. See comment on #18.

In the wake of #30, should LockProtected still be a part of the project?

In #13, @jeremy-w argues:

Why not remove LockProtected.swift and its tests file?

I argued:

I did not feel the need to remove API that is currently in use; LockProtected has been used in every project that's used Deferred so far.

And his follow-up:

It looks like dead code from the perspective of all the code remaining in Deferred. If it's effectively getting equal footing, we should maybe add some docs on it to the README as well?

Now, I'm not as sure.

Splitting off from #54:

• Make use of dispatch_queue_t generic or pluggable in some way. (Executor concept)

This aims to solve two problems: "What if I don't have a dispatch queue?" and "What if the platform doesn't have dispatch queues?"

For the former, it would be advantageous to have upon arguments take something queue-like, rather than a literal dispatch_queue_t. In Cocoa, these may be NSOperationQueue, NSManagedObjectContext, etc.

For the later, after briefly discussing with @jgallagher, we want to keep the conceptual model simple; rather than guarding upon availability to not-Linux, or to have more complex routines (like spinning up pthreads), we're going to wait for general Dispatch availability, since that'll be in the Swift 3.0/Deferred 3.0 time range anyway. This means that #54 is officially on ice for now.

API effects

API changes in this realm should be backwards-compatible.

Common criticism involves the limited uses of and. We should provide 3- and 4-arity versions as well, and recommend ways to handle greater compositions.

In 2.0b4 I believe the following code resulted in a filled future:

let filledVoidFuture = Future<Void>()

...because the value parameter was unnamed (init(_ value: Value), link). In 2.0.0, however, init() was added, and so the same code now creates a "future that will never get fulfilled".

I'm not sure this is an "issue" that needs to be resolved in any way, but I thought it worth mentioning here.

I created a unit tests that highlights this behaviour here: #142

Currently disabled due to compiler crash.

Should they return a type-erased Future instead? Or something else. Pretty sure they should not return a Deferred.