<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Whoops, dropped a `.T`, but you get the picture.<br><br>~Robert Widmann</div><div><br>2016/01/23 1:47、Developer <<a href="mailto:devteam.codafi@gmail.com">devteam.codafi@gmail.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Precisely. That's the plan.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Even if that doesn't go through, it isn't hard to just wrap it or declare a typealias yourself in an enum with no cases:</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">enum Result<E : ErrorType, T> {</div><div id="AppleMailSignature"> typealias T = Either<E, T></div><div id="AppleMailSignature">}<br><br>func foo() -> Result<FooErrorType, ResultType> {</div><div id="AppleMailSignature"> //...</div><div id="AppleMailSignature">}<br><br>~Robert Widmann</div><div><br>2016/01/23 1:34、Austin Zheng <<a href="mailto:austinzheng@gmail.com">austinzheng@gmail.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">+1.<div class=""><br class=""></div><div class="">There have been discussions about generic typealiases/newtypes on this list before. If getting something in for Swift 2 isn't a must-have, I wonder if we could leverage those features to make both camps happy. Being able to partially apply a generic type to form a new generic type would allow us to have something like:</div><div class=""><br class=""></div><div class="">enum Either<T, U> {</div><div class=""> case Left<T>, Right<U></div><div class="">}</div><div class=""><br class=""></div><div class="">typealias Result<GoodType> = Either< GoodType, ErrorType></div><div class=""><br class=""></div><div class="">Of course, the above raises the question as to whether an 'Either' that just happens to have the right type be an ErrorType should be interchangeable with the corresponding 'Result', etc.</div><div class=""><br class=""></div><div class="">However, the above proposal might be infeasible from a theoretical or implementation perspective; if that's the case let's not get sidetracked :).</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Austin</div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 22, 2016, at 10:22 PM, Developer via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">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.<br class=""><br class="">~Robert Widmann</div><div class=""><br class="">2016/01/23 1:05、Rob Mayoff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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).<br class="">
<br class="">
<a href="https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples" rel="noreferrer" target="_blank" class="">https://github.com/typelift/swift-evolution/blob/either-or/proposals/0024-either.md#motivating-examples</a><br class="">
<br class=""></blockquote><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">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.)</div><div class=""><br class=""></div><div class="">I think a Result/Success/Failure type is warranted, but I'm very skeptical about generic Either/Left/Right.</div><div class=""><br class=""></div></div></div></div>
</div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div></blockquote></body></html>