<div dir="ltr">If my memory does not fail, there has also been a discussion about adding a &quot;payload&quot; to the optional types that fit into that context.<div><br></div><div><div>Something like:</div><div><br></div><div>//Current</div><div>enum Optional&lt;T&gt;{</div><div> case Some(T)</div><div> case None</div><div>}</div><div><br></div><div>// Adding</div><div><div>enum Optional&lt;T,Error&gt;{</div><div> case Some(T)</div><div> case None(Error)</div><div> //Maybe adding support functions too</div><div>}</div><div><br></div><div>And some compiler magics to make Optional&lt;T,Error&gt; always to be convertible to Optional&lt;T&gt; (losing Error info of course)... And support to optional chaining and other current optional tricks.</div></div><div><br></div><div>In this case:</div><div><br></div><div>let some = try? foo() // some is Optional&lt;T,Error&gt;</div><div><br></div><div>some?.bar() // works</div><div><br></div><div>And we can do:</div><div><br></div><div><div>switch some{</div><div>   case .Some(let value):</div><div>   // ...</div><div>  case .None(let error):</div><div>  // </div><div>}</div></div><div><br></div><div>Other idea was presented in Swift 2/3 time frame was just:</div><div><br></div><div><div>enum Optional&lt;T&gt;{</div><div> case Some(T)</div><div> case None</div><div> var payload:Any!</div><div>}</div></div><div><br></div><div><br></div><div>I am not saying that this is the best way, but in fact it is better to think about what we can do to improve the current scenario, than to introduce another type that may or may not make everything more confusing.<br></div><div><br></div><br><div class="gmail_quote"><div dir="ltr">Em sex, 3 de nov de 2017 às 09:13, Benjamin G via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Just an idea for the type declaration : <div><br></div><div>Why not use the same ? as Optional, but with the type of the error behind :</div><div><br></div><div>Such as</div><div><br></div><div>var x: Int?Error </div><div><br></div><div>Optional Int (Int?) would be seen a special case of Result where the error type is nil.</div><div><br></div><div>The advantage of this syntax is that it would let us specify the type of the error if we want it. </div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 11:45 AM, Nick Keets via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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><br></div><div>    var x: Int‽ = 5</div><div>    var y: Int‽ = anErrorValue</div><div><br></div><div>    func foo() -&gt; Int‽ { ... }</div><div><br></div><div>    if let x = foo() {</div><div>        // x is Int</div><div>    } else {</div><div>        // somehow access the error</div><div>    }</div><div><br></div><div>    guard let x = foo() else {</div><div>        // Again somehow access the error</div><div>    }</div><div><br></div><div>    func bar() throws -&gt; String { ... }</div><div>    let x = try‽ bar()   // x is String‽</div><div>    let y = x!  // y is String</div><div><br></div><div>    // Possibly even make it throw? (just using a random symbol again)</div><div>    let z = try x¡</div><div><br></div></div><div class="m_-3098614514446488900HOEnZb"><div class="m_-3098614514446488900h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 3, 2017 at 2:02 AM, Xiaodi Wu via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">This is clearly a fine addition to the standard library; even Swift&#39;s Error Handling Rationale (<a href="https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst" target="_blank">https://github.com/apple/swift/blob/master/docs/ErrorHandlingRationale.rst</a>) mentions such an addition<br><br>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><div class="gmail_extra"><br></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="m_-3098614514446488900m_-3581290411674590963h5">On Thu, Nov 2, 2017 at 1:08 PM, Jon Shier via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="m_-3098614514446488900m_-3581290411674590963h5"><div style="word-wrap:break-word;line-break:after-white-space">Swift-Evolution:<div><span class="m_-3098614514446488900m_-3581290411674590963m_3914425453574025374m_-4434525584991225668Apple-tab-span" style="white-space:pre-wrap">        </span>I’ve written a first draft of a proposal to add Result&lt;T&gt; to the standard library by directly porting the Result&lt;T&gt; 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><br></div><div><a href="https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md" target="_blank">https://github.com/jshier/swift-evolution/blob/master/proposals/0187-add-result-to-the-standard-library.md</a></div><div><br></div><div><br></div><div>Thanks, </div><span class="m_-3098614514446488900m_-3581290411674590963m_3914425453574025374HOEnZb"><font color="#888888"><div><br></div><div>Jon Shier</div><div><br></div><div><br></div></font></span></div><br></div></div><span>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></span></blockquote></div><br></div></div>
<br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>