<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I think I'm with Sean on this one. Optionals and throwing don't have enough to do with each other to actually come up with a specific operator or method for this. I can't help but see this as two ideas glued together:</div><div class=""><br class=""></div><div class="">- "By this point in my execution I need a non-optional value, otherwise ______"</div><div class="">- "_____ happened, therefore execution has failed and I should throw an error"</div><div class=""><br class=""></div><div class="">…and I'm not sure these ideas coincide enough to be <i class="">worth</i> gluing together. There are a lot of other ways to get a non-optional value out of an optional ('??', '!', and 'guard let' with some other action), and there are a lot of other ways to fail besides an optional being nil (status code came back as error, unexpected data, connection timeout).</div><div class=""><br class=""></div><div class="">I'd like to see some real-world examples of this before we did anything with it.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 6, 2016, at 8:00, Sean Heber 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=""><div class="">Interesting, but I’m unsure if all of it is significantly better than just using the guard that is effectively inside of the operator/func that is being proposed:<br class=""><br class="">guard let value = Int("NotANumber") else { throw InitializerError.invalidString }<br class=""><br class="">It is only a couple of characters longer and already works (it’s what I use currently). If guard allowed for a special single-expression variation so that you didn’t need to specify the ugly braces or something, it’d look prettier and be nice for a lot of other situations, too:<br class=""><br class="">guard let value = Int("NotANumber") else: throw InitializerError.invalidString<br class="">guard someVal < 10 else: return false<br class="">guard mustBeTrue() else: return<br class="">// etc<br class=""><br class="">Not to derail this, but I sort of want this ability anywhere as a shorthand for a single-expression block.<br class=""><br class="">if something < 42: doThing()<br class="">for a in list: print(a)<br class=""><br class="">But I imagine that’ll never fly. :P<br class=""><br class="">l8r<br class="">Sean<br class=""><br class=""><br class=""><br class=""><blockquote type="cite" class="">On Apr 6, 2016, at 9:46 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">Pyry Jahkola and I have been plugging away on the following which is preliminary enough not to qualify as an actual draft. He prefers the Mike Ash approach. I prefer the operator approach. So we have not actually settled on which one we would actually propose despite how I've written this up.<br class=""><br class="">I'm putting this out there to try to gain a consensus on:<br class=""><br class="">* Would this be a viable proposal?<br class="">* If so, which of the options would work best within Swift's design and philosophy <br class=""><br class="">Thanks for your feedback.<br class=""><br class="">-- Erica<br class="">Introduction<br class=""><br class="">Swift's try? keyword transforms error-throwing operations into optional values. We propose adding an error-throwing nil-coalescing operator to the Swift standard library. This operator will coerce optional results into Swift's error-handling system. <br class=""><br class="">This proposal was discussed on the Swift Evolution list in the name thread.<br class=""><br class="">Motivation<br class=""><br class="">Any decision to expand Swift's set of standard operators should be taken thoughtfully and judiciously. Moving unaudited or deliberately non-error-handling nil-returning methods and failable initializers into Swift's error system should be a common enough use case to justify introducing a new operator.<br class=""><br class="">Detail Design<br class=""><br class="">We propose adding a new operator that works along the following lines:<br class=""><br class="">infix operator ??? {}<br class=""><br class="">func ???<T>(lhs: T?, @autoclosure error: () -> ErrorType) throws -> T {<br class=""> guard case let value? = lhs else { throw error() }<br class=""> return value<br class="">}<br class=""><br class="">The use-case would look like this:<br class=""><br class="">do {<br class=""> let error = Error(reason: "Invalid string passed to Integer initializer")<br class=""> let value = try Int("NotANumber") ??? InitializerError.invalidString<br class=""> print("Value", value)<br class="">} catch { print(error) }<br class=""><br class="">Note<br class=""><br class="">SE-0047 (warn unused result by default) and SE-0049 (move autoclosure) both affect many of the snippets in this proposal<br class=""><br class="">Disadvantages to this approach:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• It consumes a new operator, which developers must be trained to use<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Unlike many other operators and specifically ??, this cannot be chained. There's no equivalent to a ?? b ?? c ?? dor a ?? (b ?? (c ?? d)).<br class="">Alternatives Considered<br class=""><br class="">Extending Optional<br class=""><br class="">The MikeAsh approach extends Optional to add an orThrow(ErrorType) method<br class=""><br class="">extension Optional {<br class=""> func orThrow(@autoclosure error: () -> ErrorType) throws -> Wrapped {<br class=""> guard case let value? = self else { throw error() }<br class=""> return value<br class=""> }<br class="">}<br class=""><br class="">Usage looks like this:<br class=""><br class="">do {<br class=""> let value = try Int("NotANumber")<br class=""> .orThrow(InitializerError.invalidString)<br class=""> print("Value", value)<br class="">} catch { print(error) }<br class=""><br class="">An alternative version of this call looks like this: optionalValue.or(throw: error). I am not a fan of using a verb as a first statement label.<br class=""><br class="">Disadvantages:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Wordier than the operator, verging on claustrophobic, even using Swift's newline dot continuation.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Reading the code can be confusing. This requires chaining rather than separating error throwing into a clear separate component. <br class="">Advantages:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• No new operator, which maintains Swift operator parsimony and avoids the introduction and training issues associated with new operators.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Implicit Optional promotion cannot take place. You avoid mistaken usage like nonOptional ??? error and nonOptional ?? raise(error).<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• As a StdLib method, autocompletion support is baked in.<br class="">Introducing a StdLib implementation of raise(ErrorType)<br class=""><br class="">Swift could introduce a raise(ErrorType) -> T global function:<br class=""><br class="">func raise<T>(error: ErrorType) throws -> T { throw error }<br class=""><br class="">do {<br class=""> let value = try Int("NotANumber") ?? raise(InitializerError.invalidString)<br class=""> print("Value", value)<br class="">} catch { print(error) }<br class=""><br class="">This is less than ideal:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• This approach is similar to using && as an if-true condition where an operator is abused for its side-effects.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• It is wordier than the operator approach.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• The error raising function promises to return a type but never will, which seems hackish.<br class="">Overriding ??<br class=""><br class="">We also considered overriding ?? to accept an error as a RHS argument. This introduces a new way to interpret ?? as meaning, "throw this error instead of substituting this value".<br class=""><br class="">func ??<T>(lhs: T?, @autoclosure error: () -> ErrorType) throws -> T {<br class=""> guard case let value? = lhs else { throw error() }<br class=""> return value<br class="">}<br class=""><br class="">Usage:<br class=""><br class="">let value = try Int("NotANumber") ?? Error(reason: "Invalid string passed to Integer initializer")<br class=""><br class="">This approach overloads the semantics as well as the syntax of the coalescing operator. Instead of falling back to a RHS value, it raises the RHS error. The code remains simple and readable although the developer must take care to clarify through comments and naming which version of the operator is being used.<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• While using try in the ?? statement signals that a throwing call is in use, it is insufficient (especially when used in a throwing scope) to distinguish between the normal coalescing and new error-throwing behaviors.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Error types need not use the word "Error" in their construction or use. For example try value ?? e may not be immediately clear as an error-throwing intent.<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>• Overloading ?? dilutes the impact and meaning of the original operator intent.<br class="">Future Directions<br class=""><br class="">We briefly considered something along the lines of perl's die as an alternative to raise using fatalError.<br class=""><br class="">Acknowledgements<br class=""><br class="">Thanks Mike Ash, Jido, Dave Delong<br class="">_______________________________________________<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=""></blockquote><br class="">_______________________________________________<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></div></blockquote></div><br class=""></body></html>