This repository has been archived by the owner on Aug 29, 2022. It is now read-only.
v4.0 Beta 1: Architecture Rap Battle
Pre-release
Pre-release
zwaldowski
released this
20 Sep 16:49
·
113 commits
to master
since this release
Deferred 4.0 brings the latest and greatest of Swift to Deferred, and is optimized to be faster and easier-to-use than ever before.
- Deferred supports and requires Swift 4.1 or better. (#200, #201, #222, #237, #250, #251)
Deferred<Value>
uses up to 70% lower memory and is up to 80% faster. (#229)Task<SuccessValue>
and its related types have been redesigned to address common pain points. (#243)Collection.allSucceeded()
returns a combined array of all successes as its success value. (#217)TaskResult<Value>
provides common-casemap(_:)
andflatMap(_:)
methods. (#244)Task.fallback(upon:to:)
canthrow
from within its handler. (#245, #255)Task()
is renamedTask.never
. (#247)Task(upon:flags:onCancel:execute:)
is renamedTask.async(upon:flags:onCancel:execute:)
. (#248)- The functionality of
Task<SuccessValue>
(map(upon:transform:)
,andThen(upon:start:)
,recover(upon:substituting:)
fallback(upon:to:)
, and so on) are conditionally available onFuture
andDeferred
. (#253) Task<SuccessValue>
convenience initializers are more aligned with the Swift API Design Guidelines. (#254)Task.repeat(upon:count:continuingIf:to:)
can be used to simply re-attempt work if it fails. (#255)
Future<Value>
and its related types benefits from changes toTask<SuccessValue>
andDeferred<Value>
.- Implementing a custom
Future
requires fewer method implementations. (#215, #216) Future()
is renamedFuture.never
. (#247)Future.async(upon:flags:execute:)
can be used to capture the result of asynchronous work. (#248)Future
andDeferred
conditionally haveinit(success:)
andinit(failure:)
, instead of requiringinit(value: .success(...))
. (#254)
- Implementing a custom
- Improvements to debugging, reflection, and playgrounds. (#202, #212, #214, #223)
Protected<Value>
andTaskResult<Value>
are annotated for binary resilience in Swift. Their use across module boundaries should be much faster. (#226, #243)