<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 don't think that "guard let x? = ..." would be syntactically correct, AFAIK for matching the pattern "let x? =", as for any other pattern, you need to use "case", in fact the following is perfectly valid:</div><div class=""><br class=""></div><div class="">guard case let x? = doSomething() else {</div> // handle when nil<br class="">}<div class=""><br class=""></div><div class="">I think that "guard let x =" is in fact sugar for "guard case let x? =", so your example should really be:<br class=""><div class=""><br class=""></div><div class="">guard case let x? = try doSomething() catch {<br class=""> // handle error<br class="">} else {<br class=""> // handle when nil<br class="">}</div><div class=""><br class=""></div><div class="">This would basically mean "add an extra catch when pattern-matching with a throwing function", same as:</div><div class=""><br class=""></div><div class="">switch try doSomething() {</div><div class="">case let x?:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// handle</div><div class="">case nil:</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// handle<span class="Apple-tab-span" style="white-space:pre"> </span></div><div class="">} catch {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>// handle</div><div class="">}</div><div class=""><br class=""></div><div class="">Honestly I'm still not sold in conflating the two things. I don't think it would be problematic to clearly separate cases when I'm binding the result of a throwing function (which in fact is isomorphic to a Either<T,Error>) and binding an Optional<T>.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Elviro</div><br class=""><div><blockquote type="cite" class=""><div class="">Il giorno 10 lug 2017, alle ore 10:44, David Hart <<a href="mailto:davidhart@fastmail.com" class="">davidhart@fastmail.com</a>> ha scritto:</div><br class="Apple-interchange-newline"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><br class="Apple-interchange-newline">On 10 Jul 2017, at 09:45, Elviro Rocca 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="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">This is not a sugar proposal, in the same way as "guard" is not syntactic sugar, because it requires exiting the scope on the else branch, adding expressive power and safety to the call: also, the sugary part is pretty important because it avoids nested parentheses and very clearly states that if the guard condition is not fulfilled, the execution will not reach the next lines of code. Guard is useful to push the programmer to at least consider an early return instead of branching code paths, to achieve better clarity, readability and lower complexity, and I suspect is one of the best Swift features for many people.<br class=""><div class=""><font color="#5856d6" class=""><br class=""></font>Also, the case that the proposal aims to cover is not an edge case at all for a lot of people, including me. Rethrowing an error is something that I almost never do, and I consider the "umbrella" do/catch at the top of the call stack an anti-pattern, but I understand that many people like it and I'm not arguing against it. I am arguing in favor of having options and not pushing a particular style onto programmers, and for my (and many people's) style, a guard/catch with forced return is an excellent idea. In fact you seem to agree on the necessity of some kind of forced-returnish catch but your elaborations don't seem (to me) much better than the proposal itself.<br class=""><font color="#5856d6" class=""><br class=""></font>Dave DeLong raised the point of weird behavior in the case of a function like:<br class=""><font color="#5856d6" class=""><br class=""><br class=""></font>func doSomething() throws → Result? { … }<br class=""><font color="#5856d6" class=""><br class=""><br class=""></font>In this case, what would the type of x be?<br class=""><font color="#5856d6" class=""><br class=""><br class=""></font>guard let x = try doSomething() catch { /// handle and return }<font color="#5856d6" class=""><br class=""></font></div></div></div></blockquote><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="">I know we can’t do much about it now, but if optional binding had used the same syntax as it does in pattern matching, we wouldn’t be having this discussion:</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=""><font face="Menlo" class="">guard let x = try doSomething() catch {</font></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=""><font face="Menlo" class=""> // handle error</font></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=""><font face="Menlo" class="">}</font></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=""><font face="Menlo" class=""><br class=""></font></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=""><font face="Menlo" class="">guard let x? = doSomething() else {</font></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=""><font face="Menlo" class=""> // handle when nil</font></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=""><font face="Menlo" class="">}</font></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="">And mixing both would be a bit cleaner because the ? would make it explicit we are doing optional binding:</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=""><font face="Menlo" class="">guard let x? = try doSomething() catch {</font></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=""><font face="Menlo" class=""> // handle error</font></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=""><font face="Menlo" class="">} else {</font></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=""><font face="Menlo" class=""> // handle when nil</font></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=""><font face="Menlo" class="">}</font></div><br class="" 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;"><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Simple, it would be Optional<Result>. I don't find this confusing at all, and if the idea that just by seeing "guard let" we should expect a non-Optional is somehow diffused, I think it's better to eradicate it.<br class=""><font color="#5856d6" class=""><br class=""></font>First of all, if I'm returning an optional from a throwing function, it's probably the case that I want the Optional to be there in the returned value: the only reason why I would consider doing that is if the semantics of Optional are pretty meaningful in that case. For example, when parsing a JSON in which I expect a String or null to be at a certain key:<br class=""><font color="#5856d6" class=""><br class=""><br class=""></font>extension String: Error {}<br class=""><font color="#5856d6" class=""><br class=""></font>func parseString(in dict: [String:Any], at key: String) throws -> String? {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>guard let x = dict[key] else { throw "No value found at '\(key)' in \(dict)" }<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>if let x = x as? String { return x }<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>if let x = x as? NSNull { return nil }<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>throw "Value at '\(key)' in \(dict) is not 'string' or 'null"<br class="">}<br class=""><font color="#5856d6" class=""><br class=""><br class=""></font>Thus, if I'm returning an Optional from a throwing function it means that I want to clearly distinguish the two cases, so they shouldn't be collapsed in a single call:<br class=""><font color="#5856d6" class=""><br class=""><br class=""></font>guard let x = try doSomething() catch { /// handle and return }<br class="">guard let x = x else { /// handle and return }<br class=""><font color="#5856d6" class=""><br class=""><br class=""></font>Also, if a function returns something like "Int??", a guard-let (or if-let) on the returned value of that function will still bind an "Int?", thus unwrapping only "one level" of optional. If-let and guard-let, as of today, just unwrap a single optional level, an do not guaranteed at all that the bound value is not optional.<br class=""><font color="#5856d6" class=""><br class=""></font>To me guard-let (like if-let) is basically sugar for monadic binding for Optionals, with the additional expressivity granted by the forced return. I would love to see the same monadic binding structure applied to throwing functions.<br class=""><font color="#5856d6" class=""><br class=""><br class=""><br class=""></font>Elviro<br class=""><font color="#5856d6" class=""><br class=""><br class=""><br class=""></font><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class=""><div class="">Il giorno 09 lug 2017, alle ore 01:16, Christopher Kornher via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> ha scritto:<br class=""><blockquote type="cite" class=""></blockquote><font color="#00afcd" class=""><br class=""></font>Thanks for you considerate reply. My concern over the proliferation of “sugar proposals” is a general one. This proposal has more merit and general utiliity than many others. I have never used a throwing function in a guard statement that was not itself in a throwing function, but I can see that it could possibly be common in some code. Wrapping a guard statement and all the code that uses variables set in the guard in a do/catch is sub-optimal.<br class=""><font color="#00afcd" class=""><br class=""></font><blockquote type="cite" class=""><div class=""><div class="" style="text-align: start; text-indent: 0px;">On Jul 8, 2017, at 4:16 PM, Benjamin Spratling via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote><font color="#12c00e" class=""><br class=""><br class=""><br class=""></font>I’ve read your email, but haven’t digested it fully. One thing I agree with is that most functions which call throwing functions don’t actually use a do…catch block, but instead are merely marked “throws” and the error is propagated back through the stack. Once I seriously started coding functions with errors, I realized I almost always wanted my errors to reach my view-controller or my business logic so I could present separate UI if a real error occurred, and often my error message depended on the details of the error instance.<br class=""><font color="#12c00e" class=""><br class=""><br class=""><br class=""></font>I disagree with your conclusion on this point.<br class="">The “guard” syntax is specifically designed to achieve early return (and placing code associated with early return at the point where it happens) and cleanly installing the returned value into the surrounding scope. So far it has been used to achieve early return only with optionals, true. But is that inherent to ‘guard’, or is it merely because that’s the only way it has been used? The guard does set variables that are needed in the body of the function, and that’s exactly why using guard with values returned from throwing functions makes so much sense, because it does exactly the same thing in a general sense. The “do”…”catch” structure is intentionally designed differently, to place the “happy path” in one place and place the returns in another place. I think with guard/else, we’re seeing developers who can handle less cognitive loading find it easier to reason about early return than grouping failures after the happy path. This proposal hopes to introduce that better language architecture to the catching of errors.<br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote>On Jul 8, 2017, at 4:08 PM, Christopher Kornher <<a href="mailto:ckornher@me.com" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">ckornher@me.com</a>> wrote:<br class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></blockquote><br class="">I am opposed to this proposal because it muddies up the language to support what is essentially an edge case. The standard way to exit a function early because an exception is thrown is to make the function itself throw, if it is part of a larger operation. The addition of a few lines of try/catch code is not a great burden and makes the termination of an an exception very clear.<br class="">`guard` statements are generally used to set variables that are needed in the body of a function. Using them to save a few lines of exception handing code is a very different use. There is no need to mix two relatively clean syntaxes for a few edge cases and increase cognitive load one more time,<span class="Apple-converted-space"> </span><br class=""></div></div></blockquote></div></div></blockquote><font color="#00afcd" class=""><br class=""></font>All catches don’t have to exit the outer scope, so using guard only handles a subset <br class=""><font color="#00afcd" class=""><br class=""></font>It think that creating the terse try/catch for simple cases has multiple advantages:<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>1) I think that it addresses your desire for a simple way to use throwing functions easily in guard statements.<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>2) It avoids having to change the guard syntax to accomplish this<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>3) It is useful for handling simple one line try/catch constructs in less space in a way that should not seem too foreign to Swift developers.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>4) It simplifies code that currently uses nested do/try/catch constructs. Even though this is rare, it introduces significant “rightward drift”.<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>5) It can used to return early from void throwing functions easily. e.g. : <br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>guard try foo( ) catch { return }</div></div></div></blockquote><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>Multiple void throwing functions would probably be better handled by a do/catch block, but there is no danger of needing values from these functions because there are none:<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class=""><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>do {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>try fn1()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>try fn2()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>} catch {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// keep going, return or call a non-returning function, since throw is already handled by declaring a throwing enclosing function.<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// No varibles are needed by the outer block because none are set<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// So it is not clearly a guard-like statement<br class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}<span class="Apple-tab-span" style="white-space: pre;"> </span> </div></div></div></blockquote><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>I did not think of this before, but perhaps we could allow `do` to be replaced with `guard`, thereby allowing values to escape to the outer scope, while still ensuring an early exit:<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class=""><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>guard {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>try fn1()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>try fn2()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>let x = fn3()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>} catch {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// Must exit<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>} else {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// Must exit<br class=""><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}<span class="Apple-tab-span" style="white-space: pre;"> </span> </div></div></div></div></blockquote><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class="">I am not sure that “leaky” braces are a good idea, so perhaps some other character could be used to indicate a non-scope or whatever you want to call it:<br class=""><font color="#00afcd" class=""><br class=""></font><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class=""><blockquote type="cite" class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>guard <your favorite character here><br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>try fn1()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>try fn2()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>let x = fn3()<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span> <another favorite character here> catch {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// Must exit<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>} else {<br class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>// Must exit<br class=""><div class=""><div class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>}<span class="Apple-tab-span" style="white-space: pre;"> </span> </div></div></div></div></div></blockquote><span class="Apple-tab-span" style="white-space: pre;"> </span>```<br class="">This would make the language even harder to read, so just using braces is probably a better idea.<br class=""><font color="#00afcd" class=""><br class=""></font>This would change the guard syntax slightly, but is a straightforward extrapolation of do/catch and guard, I think. Of course, this could replace the existing guard syntax entirely and its use of semicolons, if we want to go that far…<br class=""><font color="#00afcd" class=""><br class=""></font>Allowing this syntax only if one of the expressions throws is possibly a good backward-compatible solution that would avoid redundant guard syntaxes.<br class=""><font color="#00afcd" class=""><br class=""></font>Anyway there are lot of possibilities here. We are not forced to extend the guard statement as it exists today. The current guard statement syntax was quite controversial when it was introduced and extending it may not be the best option to do what you want.<br class=""><font color="#00afcd" class=""><br class=""></font>- Chris<br class=""><font color="#00afcd" class=""><br class=""><br class=""><br class=""><br class=""><br class=""></font>_______________________________________________<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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="text-align: start; text-indent: 0px;"><font color="#12c00e" class=""><br class=""></font>-Ben Spratling<br class=""><font color="#12c00e" class=""><br class=""></font>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><div class=""><div class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></div></div></blockquote></div></div></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" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></blockquote></div><br class=""></div></body></html>