As has been mentioned by the core team, syntactic sugar is not in scope for this phase of Swift 4 evolution and was said to be the lowest priority for the next. The bar for adding a new operator is going to be higher than for justifying the continued existence of an existing one.<br><br>That said, the nil coalescing operator has problems of its own that have been raised on this list, mostly to do with sometimes unintuitive behavior as a result of its associativity and precedence.<br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 8, 2017 at 14:35 Jack Newcombe <<a href="mailto:jack@newcombe.io">jack@newcombe.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">It’s absolutely true that this is syntactic sugar, but then so is nil-coalescing where "x ?? y” is syntactic sugar for “x != nil ? x : y”. <div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">You can also similarly recreate the nil-coalescing operator in Swift yourself, so I’m not sure that’s a strong argument for any operator being or not being in the standard library.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On 8 Feb 2017, at 20:29, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_3188881196958085444Apple-interchange-newline gmail_msg"><div class="gmail_msg">This seems to boil down to sugar where `guard let foo = ... else { throw ... }` is spelled `let foo = try ... !! ...`.<br class="gmail_msg"><br class="gmail_msg">While the analysis is interesting I don't see that this is an obvious win sufficient for the standard library. As you show it's possible to create for yourself.<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Wed, Feb 8, 2017 at 14:20 Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg">While I find the concept interesting, I give a big -1 for using the ‘!’ operator for something else that fatal error.</div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">Le 8 févr. 2017 à 21:00, Jack Newcombe via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br class="m_3188881196958085444m_3149029241138271543Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg">Hi all,<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Currently there are a number of different operators for dealing with optionals that cover most of the use cases. However, I think I’ve identified a missing complement for the existing operators for optionals.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Take the following outcomes for interacting with an optional using existing operators (!, ?, ??). The outcomes of using these are as follows:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- value? : </div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>if value is nil, do nothing and return nil</div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>if value is not nil, complete the chain by evaluating the rest of the expression. Return the result of the expression</div><div class="gmail_msg">- value! : </div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>if value is nil, throw.a fatal error. </div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>If value is not nil, complete the chain by evaluating the rest of the expression. Return the result of the expression</div><div class="gmail_msg">- value ?? default :</div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>if value is nil, return default</div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>if value is not nil, return value</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It seems to me that, if it is possible to coalesce a nil value with a default value, it should also be possible to reject a nil value a non-fatal error.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I propose the introduction of a nil-rejection operator (represented here as !!) as a complement to the above operators.</div><div class="gmail_msg">.</div><div class="gmail_msg">This operator should allow an equivalent behaviour to the forced unwrapping of a variable, but with the provision of an error to throw in place of throwing a fatal error.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">- value !! Error :</div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>if value is nil, throw non-fatal error</div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>if value is not nil, return value</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Example of how this syntax might work (Where CustomError: Error):</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>let value = try optionalValue !! CustomError.failure</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">It is possible to implement this in Swift 3 with the following declaration:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>infix operator !! : NilCoalescingPrecedence<br class="gmail_msg"><br class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>func !!<UnwrappedType: Any, ErrorType: Error>(lhs: Optional<UnwrappedType>, rhs: ErrorType) throws -> UnwrappedType {<br class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span> guard let unwrappedValue = lhs else {<br class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span> throw rhs<br class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span> }<br class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span> return unwrappedValue<br class="gmail_msg"><span class="gmail_msg m_3188881196958085444m_3149029241138271543Apple-tab-span" style="white-space:pre-wrap"> </span>}</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I’ve added further examples including composition with the nil-coalescence operator here: </div><div class="gmail_msg"><a href="https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d" class="gmail_msg" target="_blank">https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d</a></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">This would be particularly convenient in cases where a functions expects significant number of optional to contain non-nil values, without the need to repeat non-generic guard-let structures with the same else code-block.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Best regards,</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Jack</div><div class="gmail_msg"><br class="gmail_msg"></div></div>_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote></div><br class="gmail_msg"></div></div></div></div></blockquote></div>