> On Dec 13, 2017, at 9:53 PM, Erica Sadun <er...@ericasadun.com> wrote:
> Chris L had a beautiful solution for an "Unwrappable" protocol that allowed 
> all of the optional sugar to be extended to any type that had a biased 
> `Wrapped` item, allowing it to be used with `Either`, `Wrapped`, etc as well 
> as form the basis for `Optional` itself.
> protocol Unwrappable {
>   associatedtype Element
>   func unwrap() -> Element?
> }

It would definitely be nice to make "Optional" sugar work for non-"Optional" 
types! (I think the goal for "async"/"await" is to make it work for any 
continuation, so it's basically Haskell "do" notation for Swift!)

I'm not sure the "Unwrappable" protocol can handle many of the examples I 
mentioned (accumulative errors, parallelism), though I wonder if it could be 
designed differently to do so. The applicative structure requires just 2 

    protocol Applicative<A>: Functor<A> {
      static func pure(_ value: A) -> Self
      static func <*> <B>(lhs: Self<(A) -> B>, rhs: Self) -> Self<B> 

Such a protocol isn't possible in Swift (yet), but it could unlock this kind of 
sugar for everyone. Here's "Optional" conformance:

    extension Optional: Applicative<Wrapped> {
      static func pure(_ value: Wrapped) -> Wrapped? {
        return value // promoted to Optional.some

      static func <*> <B>(lhs: Optional<(Wrapped) -> B>, rhs: Optional) -> B? {
        guard let lhs = lhs, rhs = rhs else { return nil }
        return lhs(rhs)

We can't conform to such an "Applicative" protocol today, but we _can_ still 
write and use these functions in a concrete manner! (Delete the conformance and 

The original post in this thread had this example:

    getPostageEstimate(source: String, destination: String, weight: Double)

If we were dealing with this function in the world of optional arguments, 
here's how we could use our abstraction:

    Optional.pure(curry(getPostageEstimate)) <*> john.address <*> alice.address 
<*> pure(2.0)

It's not _too_ bad, though it's kinda noisy, we have to maintain a bunch of 
custom code, we have to curry "getPostageEstimate" before passing it through, 
we lose our argument labels, and we're living in custom operator world, which 
can be disconcerting at first.

If Swift provided sugar over this structure, we'd merely need to do this:

    getPostageEstimate(|source: john.address, destination: alice.address, 
weight: 2.0|)

What's even neater is we can use this same format for types that wrap values in 
other ways! Let's say the addresses are coming from untrusted sources and need 
to be validated:

    getPostageEstimate(|source: try validateAddr(john), destination: try 
validateAddr(alice), weight: 2.0|)

If both addresses are invalid and "throw", we could get both errors and render 
them at once to our end user.

Another example: what if we want to get the postage estimate for two addresses 
that we need to fetch asynchronously:

    getPostageEstimate(|source: await myAddress(), destination: await 
theirAddress(), weight: 2.0|)

Such a syntax allows those requests to run in parallel and not block :)

In these examples, "Optional" promotion becomes applicative promotion ("2.0" is 
getting wrapped automatically), which might open a can of worms but it's a fun 
can to think about!

[1]: Well, technically it also requires "map", since any applicative is a 
functor, and it also requires that it follows some math laws.

swift-evolution mailing list

Reply via email to