<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">I'd say that this syntax would be even more coherent with protocol composition, given that x is effectively an Int <b class="">or</b> an Error: <div class=""><br class=""><div class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="">var x: Int | Error</div></div></blockquote></div><div class=""><br class=""></div><div class="">But aside from the specific syntax, I'm pretty sure it isn't the first time this request comes up and there were good reasons for rejecting it. </div><div class=""><br class=""><div class="">
<div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">Elia Cereda</div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">Il giorno 03 nov 2017, alle ore 13:10, Benjamin G via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> ha scritto:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Actually i'd even prefer :<div class="">var x: Int ?? Error</div><div class=""><br class=""></div><div class="">the spaces makes it more readable, it looks like what you'd do with the ?? operator already, and it seems coherent with the syntax for protocol composition.</div><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Nov 3, 2017 at 12:12 PM, Benjamin G <span dir="ltr" class=""><<a href="mailto:benjamin.garrigues@gmail.com" target="_blank" class="">benjamin.garrigues@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">Just an idea for the type declaration : <div class=""><br class=""></div><div class="">Why not use the same ? as Optional, but with the type of the error behind :</div><div class=""><br class=""></div><div class="">Such as</div><div class=""><br class=""></div><div class="">var x: Int?Error </div><div class=""><br class=""></div><div class="">Optional Int (Int?) would be seen a special case of Result where the error type is nil.</div><div class=""><br class=""></div><div class="">The advantage of this syntax is that it would let us specify the type of the error if we want it. </div><div class=""><br class=""></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class="">Right, to me there is not a lot of value in adding Result as it exists in AlamoFire. We will (eventually) use the Swift Package Manager for things like this. The value would be in integrating it like Optionals. e.g. (using a strawman symbol)</div><div class=""><br class=""></div><div class=""> var x: Int‽ = 5</div><div class=""> var y: Int‽ = anErrorValue</div><div class=""><br class=""></div><div class=""> func foo() -> Int‽ { ... }</div><div class=""><br class=""></div><div class=""> if let x = foo() {</div><div class=""> // x is Int</div><div class=""> } else {</div><div class=""> // somehow access the error</div><div class=""> }</div><div class=""><br class=""></div><div class=""> guard let x = foo() else {</div><div class=""> // Again somehow access the error</div><div class=""> }</div><div class=""><br class=""></div><div class=""> func bar() throws -> String { ... }</div><div class=""> let x = try‽ bar() // x is String‽</div><div class=""> let y = x! // y is String</div><div class=""><br class=""></div><div class=""> // Possibly even make it throw? (just using a random symbol again)</div><div class=""> let z = try x¡</div><div class=""><br class=""></div></div><div class="m_-8664348124982569376HOEnZb"><div class="m_-8664348124982569376h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">This is clearly a fine addition to the standard library; even Swift's Error Handling Rationale (<a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" target="_blank" class="">https://github.com/apple/swif<wbr class="">t/blob/master/docs/ErrorHandli<wbr class="">ngRationale.rst</a>) mentions such an addition<br class=""><br class="">What separates standard library types from other types is that they have language level support, and the wrapping and unwrapping syntax here could definitely benefit from it (`.unwrap()`--which should be `.unwrapped()` incidentally--is so much less elegant in comparison to `?` and `!` for optionals (not that `Result` should use the exact such syntax for a distinct operation)). It would be a shame to transpose a third-party `Result` to the standard library without considering if any such tweaks would substantially improve ergonomics, interconversion with Optional and throws, etc.<br class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><div class=""><div class="m_-8664348124982569376m_-3581290411674590963h5">On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="m_-8664348124982569376m_-3581290411674590963h5"><div style="word-wrap:break-word;line-break:after-white-space" class="">Swift-Evolution:<div class=""><span class="m_-8664348124982569376m_-3581290411674590963m_3914425453574025374m_-4434525584991225668Apple-tab-span" style="white-space:pre-wrap"> </span>I’ve written a first draft of a proposal to add Result<T> to the standard library by directly porting the Result<T> type used in Alamofire to the standard library. I’d be happy to implement it (type and tests for free!) if someone could point me to the right place to do so. I’m not including it directly in this email, since it includes the full implementation and is therefore quite long. (Discourse, please!) </div><div class=""><br class=""></div><div class=""><a href="https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md" target="_blank" class="">https://github.com/jshier/swif<wbr class="">t-evolution/blob/master/propos<wbr class="">als/0187-add-result-to-the-sta<wbr class="">ndard-library.md</a></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Thanks, </div><span class="m_-8664348124982569376m_-3581290411674590963m_3914425453574025374HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div><div class="">Jon Shier</div><div class=""><br class=""></div><div class=""><br class=""></div></font></span></div><br class=""></div></div><span class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></span></blockquote></div><br class=""></div></div>
<br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailma<wbr class="">n/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div>
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>