JSoto
Re:Twitter launches Fabric mobile app for developers
on Tuesday February 23, 2016 @06:48PM (#11163350)
iOS engineer who worked on the Fabric app here :) I gave a talk about this topic at a Swift conference last year, if you wanna check that out! https://www.youtube.com/watch?v=Ent6LJDIB3I
Re:Functor and Monad in Swift
on Friday January 02, 2015 @04:57PM (#8828799)
Oh yeah that's a good point! (and a really interesting optimization that can be applied to immutable values)
Re:Functor and Monad in Swift
on Friday January 02, 2015 @03:48PM (#8828458)
I agree that it would be a little cleaner, because it would express the intention better (the fact that you're simply giving out the same error). However, the type would be wrong:
Yeah, this is correct. This would be wrong:
func map<U>(f: T -> U) -> Result<U> {
switch self {
case let .Value(value):
return Result<U>.Value(Box(f(value.unbox)))
case let .Error(error):
// self is Result<T>, but the return type must be Result<U>
return self
}
}
As for efficiency: like you mention, enum are value types. For this reason, they're passed by copy! So even returning self would return a copy of self, not the same instance :)
Re:Functor and Monad in Swift
on Friday January 02, 2015 @03:45PM (#8828444)
Yeah, this is correct. This would be wrong:
func map<U>(f: T -> U) -> Result<U> {
switch self {
case let .Value(value):
return Result<U>.Value(Box(f(value.unbox)))
case let .Error(error):
// self is Result<T>, but the return type must be Result<U>
return self
}
}
Re:Functor and Monad in Swift
on Friday January 02, 2015 @03:44PM (#8828437)
Thanks!
I think that would make for another interesting article. I purposely ignored those details to make sure I kept my article more practical and less academic :) I also didn't mention the unit function of Monads (is that equivalent to one of the laws that you refer to?)