<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">Hi,</div><div><br></div><div><br></div><div># Introduction</div><br><div class="bloop_sign" id="bloop_sign_1449521438123563008"><div class="bloop_sign" id="bloop_sign_1449521438123563008">I'd like to propose a non-invasive way of extending the funtionality of `if let` conditional binding (and potencially other Optional-related language constructs) by introducing `CustomOptionalConvertible` protocol. The idea is basically the same as with `CustomStringConvertible` protocol used to provide string interpolation or with `~=` operator used in `switch` statement pattern matching. I believe it's going to simplity and unify the use of the Optional-related family of Swift syntax constructs for custom types.</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">The proposal is in a draft stage right now, I'll clear it up if it proves worth to be pull-requested.</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"># Motivation</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">One of the Swift features that are core to it's safety and readability are Optionals. They're important enough to be given special place in the language syntax. Special operators like `?`, `!` or `??`, special casting keywords like `as?`, special conditional binding `if let`. The Optionals, however, might be also seen as a member of larger family of constructs: call them monads, boxes, value containers, computational context bearers. One example of those would be a very similar type going by the name of Either, Try or Result. It can be seen as an Optional that carries some additional information about the reason why the value is absent. That information is not always of our interest and in those cases conditional binding for Either type makes a lot of sense. However, the `if let` syntax is currently exclusively working only for optionals.</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"># Proposed solution</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">While I'd love to see Swift introducing a powerful construct similar to Haskell's `do-notation` or Scala's `for-comprehension`, I believe it'd require a significant invasive change in the language implementation (and, possibly, vision). Therefore the proposed solutions is much more humble. Let's introduce the `CustomOptionalConvertible` protocol with signature:</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">protocol CustomOptionalConvertible {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>typealias Wrapped</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>public var optional: Optional<Wrapped> { get }</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">Such a protocol will provide a way for an arbitrary type to convert to the Optional. All the types implementing this protocol could then be used in conditional binding syntax without explicit declaration of conversion. I do not propose the introduction of general implicit conversion construct, just a special case. The same as `CustomStringConvertible` is a special case of allowing the value to express itself in the string interpolation.`CustomOptionalConvertible` will allow the author of an arbitratry type to integrate with Swift syntax:</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">enum Either<Value> {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>case Left(ErrorType)</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>case Right(Value)</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">extension Either : CustomOptionalConvertible {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>typealias Wrapped = Value</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>public var optional: Optional<Value> {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>get {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>switch (self) {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>case .Left(_): return .None</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>case .Right(let value): return .Some(value)</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>} </div><div class="bloop_sign" id="bloop_sign_1449521438123563008">}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">func foo(either: Either<String>) -> String {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>if let string = either {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>return string</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>} else {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>return "No value"</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">There is already a similar mechanism available in the context of pattern matching: `~=` operator.</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"># Impact on the language</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">While I cannot say much about the impact on the compiler, I believe the introduction will bring no breaking change to the Swift language itself. All the places that are currently requiring Optionals will still require Optionals. </div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">For the language users it'll make it easier to integrate the constructs used in the program with the native syntax, making them easier to use and read. Current solution, namely:</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">func foo(either: Either<String>) -> String {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>if let string = either.optional {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>return string</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>} else {</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>return "No value"</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><span class="Apple-tab-span" style="white-space:pre"> </span>}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">}</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">is introducing unnecessary noise in the otherwise neat syntax. The problem escalates when `if let` cascade is used:</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">if let string = eitherString.optional</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"> int = eitherInt.optional</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"> array = eitherArray.optional </div><div class="bloop_sign" id="bloop_sign_1449521438123563008">// ...</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">```</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"># Alternatives considered</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">The equivalent of Haskell’s `do-notation`. It’s a powerful construct (some say even too powerful, see <a href="https://wiki.haskell.org/Do_notation_considered_harmful">https://wiki.haskell.org/Do_notation_considered_harmful</a>). However, I can’t imagine it without significant changes to the language syntax (`if let` should return value) and vision (I believe that Optional are syntactic unicorns by design).</div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008"><br></div><div class="bloop_sign" id="bloop_sign_1449521438123563008">All the best,</div><div class="bloop_sign" id="bloop_sign_1449521438123563008">Krzysztof</div></div></body></html>