The future of PromiseKit

[GarthSnyder]

Now that WWDC has come and gone, I'd be curious to hear general thoughts on the future of PromiseKit. (Especially @mxcl's, of course.)

Unless I missed something, there weren't any significant changes to Combine this year, so I guess Apple considers it complete. It's not really a potential moving target anymore.

I do not think Combine replaces PromiseKit. I like Combine more than RxSwift (the only other streaming system I've actually used), but despite the general similarities, PromiseKit is still a much nicer API for the use cases it targets. I hope and plan to continue using it (or something like it) in the future.

However, PromiseKit is living in Combine's world now, so it seems like it needs a Combine-aware overhaul to exploit conceptual similarities. And I suspect that a large part of the PromiseKit API could be reimplemented as a layer over Combine, slimming both the codebase and the maintenance burden. Is this reasonable or is it crazy talk?

Things that seem at first glance like they ought to be shared with Combine:

• General terminology
• Dispatching/scheduling system
• Cancellation system
• Platform-supported APIs that vend promises/publishers
• Multiple downstream links require explicit .shared()

Things that seem like they should continue to work differently for promises:

• Only one error or one result (duh)
• Promises are self-retaining and self-freeing; no need for retainer objects
• Errors are always thrown; no separate error transmission or receiving API
• No operators that disallow throwing
• No client protocols to implement - chain structure determines behavior
• No subscriptions
• No backpressure/connectability/demand management
• ensure and finally
• Resolver API (aka "seal" or what Combine calls a Promise)
• Errorless chains are a separate type (Guarantee)
• Promises retain their result until deallocated

Some of this is potentially painful. E.g., then makes a heck of a lot more sense than flatMap for what it does, especially in the context of promises.

Most of the v7 work I've done on PromiseKit seems irrelevant to a post-Combine world. I'm not sure to what extent that extends to other aspects of v7. In any case, I don't have any problem ditching all that in favor of something more responsive to the current situation.

[ghost]

Not an expert by any means, but I've always felt that PromiseKit and RxSwift are two quite different paradigms and best suited to solving different problems. Especially after working on a project where the devs decided to use RxSwift for tasks that PromiseKit could have done with less fuss and bother. I think PromiseKit has a strong future ahead of lit where as if I was working on RxSwift I'd be nervous. Rx has a lot of functionality, but that also brings a lot of complexity and I can't see any reason why I wouldn't switch to Combine for a new project that needed to stream data.

Can PromiseKit be refactored on top of Combine? I don't know. I'm no expert, but IMHO I'd be weary of doing it unless there was a really compelling gain to be had.

[jcayzac]

Hi,

This discussion seems stale, as well as the one in #1146.

Combine is iOS 13+ only, which is still a couple years from now as a minimum requirement for most apps. Ours currently use PK6 and we were looking forward to PK7. Should we abandon it for https://github.com/cx-org/CombineX instead?

[guidedways]

I personally love the semantics offered by PromiseKit and would hate to give it up for anything else. Having used Combine and RxSwift, I find that PromiseKit has a well deserved spot amongst the rest, almost aiming to solve a completely different problem. I've been using PK7 alpha and looking forward to its future.

[rzulkoski]

@mxcl Any updates on when we can expect a public release of PK7 to drop? Really looking forward to cancellation support!

[jcayzac]

People waiting for PK7 may have a look here maybe.