[swift-evolution] [proposal] Either in the Swift Standard Library
devteam.codafi at gmail.com
Sat Jan 23 00:22:21 CST 2016
My overwhelming concern, after having a conversation with Chris, is that implementing a Result<T> means we are strongly implying a particular semantics and use case when we could generalize and abstract for no cost but an extra generic parameter. In F#, Core.Choice can be used to build a Validation or Result monad, but the converse is impossible.
2016/01/23 1:05、Rob Mayoff via swift-evolution <swift-evolution at swift.org> のメッセージ:
>> Just added a section of motivating examples to the Either proposal. Ping me if you have any more that I missed ('cause I'm sure I did miss a lot).
> Your motivating examples (including all the projects you linked except "Any many more") overwhelmingly use the Either (or similar type) to represent success/failure. I'm not sure there's a single example where the names Left and Right actually make sense in the problem domain. I'm not 100% sure about func alternate in Madness/Alternation.swift. It definitely uses Left/Right to mean Failure/Result, but I couldn't tell if it also uses them as something else. Which makes those names all the more maddening.
> I checked my company's largest Scala project, which is over 300,000 lines. We use Scala's Try/Success/Failure in dozens of places. We use Either/Left/Right once, in a thrown-together report-generating script, which would probably have been written in awk or perl if it didn't need to read binary log files. (The ability of IntelliJ to reliably find all uses of a class or method is not to be underestimated. Hint hint, team Xcode.)
> I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution