
<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Imho it would be better not to add "uwrap".<div class="">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 class="">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 class="">It is quite clear that "if let" declares a new value, whereas "unwrap" introduces ambiguity.</div><div class=""><br class=""></div><div class="">Have a look at this line:</div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #bb2ca2" class="">if</span><span style="font-variant-ligatures: no-common-ligatures" class=""> unwrap someObject.someFunction() { print("?") }</span></div></div><div class="">Should the compiler accept it?</div><div class="">If yes: Should it be possible to access the return value of someFunction? How?</div><div class="">If no: What about "someObject.someComputedProperty"? What if you exchange "someObject" with "self"?</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">There might be good answers for all those questions, but they aren't obvious.</div></body></html>