<div dir="ltr">I think I agree with Tino, the use-case of “unwrap” for shadowing is not compelling enough to justify adding a keyword.<div><br></div><div>Moreover, regarding the generalized enum associated-value extraction situation, the approach I described earlier is copacetic to both destructuring tuples and leaving them intact. For example, with this enum from Erica’s revised proposal:</div><div><br></div><div><div><font face="monospace, monospace">enum Response {</font></div><div><font face="monospace, monospace"> case contact(code: Int, message: String)</font></div><div><font face="monospace, monospace"> case failure</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div>We can extend it like so:</div><div><br></div><div><div><font face="monospace, monospace">extension Response {</font></div><div><font face="monospace, monospace"> var contact: (code: Int, message: String)? {</font></div><div><font face="monospace, monospace"> if case let .contact(x) = self { return x }</font></div><div><font face="monospace, monospace"> return nil</font></div><div><font face="monospace, monospace"> }</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div>And then access its associated values either as a tuple or as separate variables:</div><div><br></div><div><div><font face="monospace, monospace">let r = Response.contact(code: 6, message: "Seven")</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">if let t = r.contact {</font></div><div><font face="monospace, monospace"> print(t.code, t.message)</font></div><div><font face="monospace, monospace">}</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">if let (c, m) = r.contact {</font></div><div><font face="monospace, monospace"> print(c, m)</font></div><div><font face="monospace, monospace">}</font></div></div><div><br></div><div>To make this work without manually implementing the boilerplate extension, I propose either a magic “Unwrappable” protocol which when conformed to by an enum will automatically generate the equivalent of that boilerplate, or else an “@unwrappable” attribute that can be applied to individual enum cases (and perhaps to an enum declaration if every case with an associated value should have it).</div><div><br></div><div>Furthermore, in the special case of an enum with only one unwrappable case, we could add sugar to make it “act like” an Optional for conditional binding, meaning eg. “.contact” could be elided and it would be usable as:</div><div><br></div><div><font face="monospace, monospace">if let x = r { … }</font></div><div><br></div><div>I think this makes for better code and a simpler language than the proposed alternatives involving an “unwrap” keyword, and it does not involve any source-breaking changes. It also lifts conditional-binding from a niche Optional-only feature, to a user-accessible tool for enums broadly.</div><div><br></div><div>Nevin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 2, 2016 at 12:53 PM, Tino Heth via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Imho it would be better not to add "uwrap".<div>Yes, it might be nicer in some situations, but it is also nice to have a simple (or at least less complicated) language.</div><div>For me, the actual benefit is to low to justify a separate keyword which creates questions that don't exist with the current syntax.</div><div>It is quite clear that "if let" declares a new value, whereas "unwrap" introduces ambiguity.</div><div><br></div><div>Have a look at this line:</div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:Menlo"><span style="font-variant-ligatures:no-common-ligatures;color:#bb2ca2">if</span><span style="font-variant-ligatures:no-common-ligatures"> unwrap someObject.someFunction() { print("?") }</span></div></div><div>Should the compiler accept it?</div><div>If yes: Should it be possible to access the return value of someFunction? How?</div><div>If no: What about "someObject.<wbr>someComputedProperty"? What if you exchange "someObject" with "self"?</div><div><br></div><div>What if I want to modify an unwrapped value? "if var" is quite intuitive, but unwrap… maybe it depends on the original value, or is there a second variant?</div><div><br></div><div>There might be good answers for all those questions, but they aren't obvious.</div></div><br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div>