[swift-evolution] API Guidelines for Asynchronous Completion Handlers?
david at hartbit.com
Thu Dec 3 16:52:55 CST 2015
A couple of points to think about:
- Seems to me like Swift's error handling should be discussed at the same time because asynchronous callbacks is the only case where we need to revert back to using NSError instead of using Swift’s error handling. What can the language do for us?
- This is slightly off-topic, but do we profit from Swift as a new language to move to a completely different paradigm like Promises?
> On 03 Dec 2015, at 23:15, Douglas Gregor <dgregor at apple.com> wrote:
>> On Dec 3, 2015, at 12:32 PM, Dan Stenmark <daniel.j.stenmark at gmail.com <mailto:daniel.j.stenmark at gmail.com>> wrote:
>> There’s a some of debate in the community regarding best practice for asynchronous completion callbacks. These practices include:
>> - Single Block w/ Mutually Exclusive Result and Error Objects (the current standard convention in Cocoa, though originally designed with Objective-C in mind)
>> - Double Block (one for success, one for failure)
>> - Swift Enum w/ Associated Objects (as described here: http://www.developerdave.co.uk/2015/09/better-completion-handlers-in-swift/ <http://www.developerdave.co.uk/2015/09/better-completion-handlers-in-swift/>)
>> Even prior to Swift, Apple’s code guidelines never explicitly addressed this topic. Going forward into the brave new world of Swift, are there going to be new preferred API design guidelines for this?
> This is a great point, and there are a number of other issues related to callbacks/closure arguments that would benefit from guidelines. For example, I've seen the “Double Block” case where the second block ends up being a trailing closure, which makes for non-intuitive uses.
> - Doug
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution