The power of Result types in Swift
swiftbysundell.com
The power of Result types in Swift
1–10 of 77 posts
Re: The power of Result types in Swift
#2I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/. In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. Neat little metaphor.
Re: The power of Result types in Swift
#3I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…
We're planning on using a similar strategy to ROP in Dark (https://darklang.com). My suspicion is that editor support for "happy path programming" can make a huge difference in how easy it is to write safe code.
Re: The power of Result types in Swift
#4I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…
What I found interesting is that if you have a pipe/filter architectural style, your happy path stays completely free of error handling, because when a filter doesn't have a good result, it just doesn't pass any data to the next filter in line. Done!
You can then centralize the error handling by having a "stderr"-like output on your filters.
When you have a call/return architectural style, you need to return something, and thread the result along, making things more complicated.
Re: The power of Result types in Swift
#5[deleted]
Re: The power of Result types in Swift
#6This only pushes the responsibility down lower in the stack. Somewhere someone would have to handle a state where we have data and error being nil at the same time.
Re: The power of Result types in Swift
#7This only pushes the responsibility down lower in the stack. Somewhere someone would have to handle a state where we have data and error being nil at the same time.
No it doesn't. This article is specifically about how you can use the Swift type system to prevent that from happening. You get a compile time guarantee that the result will either be data or error.
Re: The power of Result types in Swift
#8This only pushes the responsibility down lower in the stack. Somewhere someone would have to handle a state where we have data and error being nil at the same time.
Not necessarily. The way that the enumerated type is declared, the associated types of the success and failure values are declared to be normal (not optional). This restricts nil from being passed in as the data or the error.
Re: The power of Result types in Swift
#9This only pushes the responsibility down lower in the stack. Somewhere someone would have to handle a state where we have data and error being nil at the same time.
Actually, it puts the responsibility higher in the stack. The first error effectively terminates the computation, so subcomputations can ignore them and the caller can decide what to do with them.
One good thing about this is not having to push down anything to do with logging or reporting into subcomputations.
Re: The power of Result types in Swift
#10It seems like a major legacy of practical experience with FP in the 200x and 201x years is going to be result types.