<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Hi Jon,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Actually I use Alamofire in the product I'm currently using. It's great!</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">My interest was how an "async-await" system would work with closures where it abstracts away the result internal implementation detail as John McCall mentioned. I'm not familiar with much C# to see how that works with Lambdas in that language, just curious :).</div><div id="AppleMailSignature"><br>- Rod</div><div><br>On 3 May 2017, at 6:59 am, Jon Shier <<a href="mailto:jon@jonshier.com">jon@jonshier.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><span class="Apple-tab-span" style="white-space:pre"> </span>If you want to see how Result and URLSession interact, take a look at the internals of Alamofire. We use our own Result type to encapsulate the end result of the chain of events involved in making a request and processing a response. I’ve also used this Result to form the basis of two slightly different networking implementations using ProcedureKit, and it allows very powerful and compact error passing and handling. For me, it’s far easier to work with a Result than handle errors. So while the core team’s reasoning for not including it make a bit of sense to me, it’s a major pain point for anyone doing async work now, and the conflicting solutions the community has come up with are painful to use at the same time. Plus, it’s not as if it would be much work to implement, as it has been already, multiple times, by multiple authors. <div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Jon Shier</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On May 1, 2017, at 5:48 PM, Rod Brown 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 2 May 2017, at 2:34 am, John McCall <<a href="mailto:rjmccall@apple.com" class="">rjmccall@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On May 1, 2017, at 9:01 AM, Rod Brown via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div dir="auto" class=""><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">I agree that the key problem with the current architecture that you're alluding to is it can't be easily</span><span class="" style="background-color: rgba(255, 255, 255, 0);"> </span><i class="" style="background-color: rgba(255, 255, 255, 0);">stored and transferred.<span class="Apple-converted-space"> </span></i><span class="" style="background-color: rgba(255, 255, 255, 0);">Swift errors are great for live action but holding and passing after the throwing event is problematic, and this is an elegant solution. </span><span class="" style="background-color: rgba(255, 255, 255, 0);">The storage issue is when holding it as a property, and </span><span class="" style="background-color: rgba(255, 255, 255, 0);">the transferring issue is when passing it to a closure as a results of an asynchronous operation etc. These are both definitely cases where storage of the type-or-error makes perfect sense.</span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">I think the key problem getting this accepted by the Swift Team will be that it doesn't currently have any specific use in the standard library. As a low level set of types, errors are generated by the lower levels but rarely stored, so the Standard library doesn't need the storage. Generally the only place we have to do that is in end user code. And currently the standard library doesn't have to support asynchronous operations natively, so there's nothing inside the kit that would require it to do completion handlers with errors.</span></div></div></div></blockquote><div class=""><br class=""></div>We've definitely considered including a Result type, but our sense was that in an ideal world almost no code would be using it. It's hard to imagine an ordinary API that ought to be returning a Result rather than throwing, and once you've defined that away, the major remaining use case is just to shift computation around, like with a completion handler. That explicit computation-shifting pattern is something we're hoping to largely define away with something like C#'s async/await, which would leave Result as mostly just an implementation detail of such APIs. We didn't want to spend a great deal of time designing a type that would end up being so marginal, especially if the changing role would lead us into different directions on the design itself. We also didn't want to design a type that would become an obstacle to potential future language changes like, say, typed throws.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">The downside, of course, is that as long as we lack that async/await design, computation-shifting isn't real great.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">John.</div></div></blockquote><div class=""><br class=""></div><div class="">This makes sense and is sensible. I’m curious how such an API would play with the existing NSURLSession completion handlers and the like, but I’m sure the community can design something appropriate.</div><div class=""><br class=""></div><div class="">I think the only remaining case is simply storing a result-or-error for later handling, storage to disk, etc. I agree with your contention that the vast majority of the use case for this type is for computation shifting. I think it would and should be rare that we would want to “store” as a variable the “result-or-error” type. Errors should be handled at runtime in the vast majority of cases, presented to the user or otherwise handled, and then moved on from, with the reason no longer being relevant.</div><div class=""><br class=""></div><div class="">As you say, in the meantime, it does leave computation-shifting a bit ad-hoc and convoluted, but I think the community has standardized on the Result temporary solution.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="auto" class=""><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);"><br class=""></span></div><div class=""><span class="" style="background-color: rgba(255, 255, 255, 0);">This would therefore be an element in the standard library purely so we don't have 50,000 different libraries with 50,000 different result types. I'd love to see this standardised so frameworks were more compatible. I'm just not sure whether the Core Team would see it as pressing to try and officiate a certain type that they themselves don't use.</span></div></div></div></blockquote></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=""><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></body></html>