<div dir="ltr">Gonna put in my 2 cents re shadowing being a source of bugs: I use explicit self everywhere in my codebase and it pairs wonderfully with shadowing, making the detailed example moot. As far as Dany's message, I think that's the best way to go forward with an unwrap keyword--just make it work exactly like if let x = x; not sure what other behavior was being discussed. Another way to go, though, if we're really worried about shadowing on mutable properties causing issues, would be to just have nullity inference on constants, so if you said "let x = someNullableValue; if x != nil { /* x would be inferred to be non-null here */ }". Kotlin does this very, very successfully. (But my biggest reservation with such an implementation in practice, in Kotlin, is that it only works for immutable properties. Which is why I'm fully +1 on the unwrap statement. People are going to shadow. Let them do it in a cleaner way.)</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Nov 1, 2016 at 9:47 PM Dany St-Amant via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> Le 31 oct. 2016 à 17:44, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> a écrit :<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
>> On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg">
>><br class="gmail_msg">
>> An alternative that would seem to satisfy some objections is to have a distinct "unwrap" statement--as in: "unwrap x else { ... }".<br class="gmail_msg">
><br class="gmail_msg">
> I'd be against this alternative as it is doing the work of a guard statement (including the "must exit scope" rule) with a new keyword and unneeded redundancy.<br class="gmail_msg">
><br class="gmail_msg">
> Adding "unwrap" is local. It performs one very common task with added safety (avoids unintended shadow effects) and introduces succinctness and clarity. In other words, it is a highly focused changed with a measurable benefit in use.<br class="gmail_msg">
><br class="gmail_msg">
> Compare:<br class="gmail_msg">
><br class="gmail_msg">
> * "Introduce the unwrap statement that acts like guard but is limited to optionals" creates unnecessary language verbosity.<br class="gmail_msg">
><br class="gmail_msg">
> * "guard x else ", meaning "treat optional values differently than all other items in a conditional list", fails because it obscures rather than adds intent. Worse, it would lead to issues with Boolean optionals whose wrapped value is later used within the same condition.<br class="gmail_msg">
><br class="gmail_msg">
> Xiaodi, you mentioned an alternative approach and I'd love a peek at what that is.<br class="gmail_msg">
<br class="gmail_msg">
Also with the 'guard unwrap', the following code make sense:<br class="gmail_msg">
<br class="gmail_msg">
guard unwrap x, x == 10 else { return }<br class="gmail_msg">
<br class="gmail_msg">
With a lone unwrap it would not.<br class="gmail_msg">
<br class="gmail_msg">
unwrap x, x == 10 else { return }<br class="gmail_msg">
<br class="gmail_msg">
I personally do not like shadowing, but a standalone 'unwrap!' could be of interest to those loving life in the shadows. Beside the shadowing itself, it should not be any worst than any of the other '!' usage. The feasibility of such depends of course on how the compiler manages its variable scoping.<br class="gmail_msg">
<br class="gmail_msg">
On further thought, if we were to make the, sorry bad word coming, code-breaking change to disallow legacy shadowing 'let x=x' and force the shadowing to be done exclusively via this 'unwrap' keyword, it could make it easier for projects/companies to ban shadowing.<br class="gmail_msg">
<br class="gmail_msg">
Dany<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>