<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="">It doesn’t seem from reviewing the thread that there was much consensus regarding whether this is something that should be added or how it would be spelled, so probably needs more pitching before making it to a proposal.</div><div class=""><br class=""></div><div class="">My own personal preference: Since ! is so strongly associated with force-unwrapping, using !! for throwing not trapping doesn’t seem appropriate.&nbsp;</div><div class=""><br class=""></div><div class="">I would rather see !! used for something slightly different, which is force-unwrap with an explanation. e.g.&nbsp;</div><div class=""><br class=""></div><div class="">&nbsp; someOptional !! “this should never be nil for reasons”&nbsp;</div><div class=""><br class=""></div><div class="">would be equivalent to the expression:</div><div class=""><br class=""></div><div class="">&nbsp; someOptional != nil ? someOptional! : fatalError(“this should never be nil for reasons”) &nbsp;// not that this compiles but you get the idea</div><div class=""><br class=""></div><div class="">Justification being: force unwrap isn’t universally bad despite what you might hear sometimes, and can be read as a precondition that nil is impossible/unhandleable at this point in the code. But&nbsp;preconditions should usually be accompanied with an explanation to output when they fail, which postfix ! doesn’t allow for but infix !! would.</div><div class=""><br class=""></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Feb 20, 2017, at 10:22 AM, Jack Newcombe via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">Hi all,<div class=""><br class=""></div><div class="">Now that phase 2 has begun, am I able to submit a proposal for this?</div><div class=""><br class=""></div><div class="">Best regards,</div><div class=""><br class=""></div><div class="">Jack</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 8 Feb 2017, at 20:00, Jack Newcombe &lt;<a href="mailto:jack@newcombe.io" class="">jack@newcombe.io</a>&gt; 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="">Hi all,<div class=""><br class=""></div><div class="">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=""><br class=""></div><div class="">Take the following outcomes for interacting with an optional using existing operators (!, ?, ??). The outcomes of using these are as follows:</div><div class=""><br class=""></div><div class="">- value? :&nbsp;</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>if value is nil, do nothing and return nil</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </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="">- value! :&nbsp;</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>if value is nil, throw.a fatal error.&nbsp;</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </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="">- value ?? default :</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>if value is nil, return default</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>if value is not nil, return value</div><div class=""><br class=""></div><div class="">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=""><br class=""></div><div class="">I propose the introduction of a nil-rejection operator (represented here as !!) as a complement to the above operators.</div><div class="">.</div><div class="">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=""><br class=""></div><div class="">- value !! Error :</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>if value is nil, throw non-fatal error</div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>if value is not nil, return value</div><div class=""><br class=""></div><div class="">Example of how this syntax might work (Where CustomError: Error):</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>let value = try optionalValue !! CustomError.failure</div><div class=""><br class=""></div><div class="">It is possible to implement this in Swift 3 with the following declaration:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre">        </span>infix&nbsp;operator&nbsp;!! : NilCoalescingPrecedence<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>func&nbsp;!!&lt;UnwrappedType:&nbsp;Any,&nbsp;ErrorType:&nbsp;Error&gt;(lhs:&nbsp;Optional&lt;UnwrappedType&gt;,&nbsp;rhs:&nbsp;ErrorType)&nbsp;throws&nbsp;-&gt;&nbsp;UnwrappedType {<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp;&nbsp;guard&nbsp;let&nbsp;unwrappedValue&nbsp;=&nbsp;lhs&nbsp;else&nbsp;{<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;throw&nbsp;rhs<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp; }<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>&nbsp; &nbsp;&nbsp;return&nbsp;unwrappedValue<br class=""><span class="Apple-tab-span" style="white-space:pre">        </span>}</div><div class=""><br class=""></div><div class="">I’ve added further examples including composition with the nil-coalescence operator here:&nbsp;</div><div class=""><a href="https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d" class="">https://gist.github.com/jnewc/304bdd2d330131ddb8a1e615ee560d1d</a></div><div class=""><br class=""></div><div class="">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=""><br class=""></div><div class="">Best regards,</div><div class=""><br class=""></div><div class="">Jack</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></div></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=""></body></html>