Throwing overloads about swift-overture HOT 4 CLOSED

Oh nice! If that's the case and there are no conflicts, then I'm good with overloads!

from swift-overture.

This sounds reasonable to me! We'd def take a PR for this.

from swift-overture.

Hm, one consideration is composing throwing functions with non-throwing functions, which wouldn't be scalable with overloads.

pipe((A) throws -> B, (B) -> C)
// (A) throws -> C

So we'd probably want a way to "cast" non-throwing functions into throwing ones for the sake of composition. Something like:

pipe((A) throws -> B, throwing((B) -> C))
// (A) throws -> C

We typically compose with types, and throws complicates this. So one alternative direction to consider would be to introduce a Result or Either type with which we can convert between the throwing and non-throwing world.

unthrow((A) throws -> B) -> (A) -> Either<Error, B>
throwing((A) -> Either<Error, B>) -> (A) throws -> B

Not sure what direction we wanna go here...so maybe hold off on that PR after all, sorry!

from swift-overture.

I already played a bit around with this and defined a throwing chain3 in a playground.
As Swift allows non-optionals to be passed as optionals, it also allows non-throwing functions to be passed as a throwing function.

Below an example usage directly copied from my playground. The non-throwing chain3 can still be used without any problems. In this case they were defined on ([T], A) as I was experimenting with an arguments parser for CLIs.

func chain<Element, A, B, C>(
    _ f: @escaping ([Element]) throws -> ([Element], A),
    _ g: @escaping ([Element]) throws -> ([Element], B),
    _ h: @escaping ([Element]) throws -> ([Element], C)
) -> ([Element]) throws -> (A, B, C)

let (isVerbose, whoToGreet, _) = try with(["-v", "hi"], chain(
    flag("verbose", "v"), // does not throw
    argument(named: "Name"), // throws
    exhaust // throws
))

from swift-overture.