<div dir="ltr">As for 1, isn't the compiler allowed to optimize away self.foo call?<div><br></div><div>More generally. if we have</div><div><br></div><div>class X { let const = 4 }</div><div><br></div><div>let x = X()</div><div>let closure = { print(x.const) }</div><div><br></div><div>is the compiler required to actually capture x? Can't it rewrite closure as { print(4) }? I feel like memory semantics is/should be an implementation detail.<br></div><div><br></div><div>Ilya.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 8:28 PM, Gwendal Roué <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">I’m really not found at all of having `let` properties captured by closures when used without explicit `self`.<br>
<br>
Three reasons:<br>
<br>
REASON 1. When `self` is not mandatory, then adding self should have no impact whatsoever.<br>
<br>
Why should one add a self that is not mandatory?<br>
<br>
1. for symmetry (1):<br>
<br>
self.foo = other.foo<br>
let delta = self.x - other.x<br>
<br>
2. for symmetry (2):<br>
<br>
init(a:String, index:Int) {<br>
<a href="http://self.name" rel="noreferrer" target="_blank">self.name</a> = name<br>
self.position = index+1 // keep 1-based value for implementation reasons<br>
}<br>
<br>
3. add your own reasons to use an explicit self even when not required, and I’m sure you did.<br>
<br>
So generally speaking, using self when not mandatory should have no impact on the program at all.<br>
<br>
<br>
REASON 2. What happens when a property starts its life as `let`, but turns `var` eventually? For example, the property eventually becomes lazy. OK now it’s is illegal to use the property without explicit `self` in closures, and you break a bunch of code. And you need to bump the major version of your package. Just because you turn a `let foo: String` into `lazy var foo: String = …`.<br>
<br>
That’s not good at all.<br>
<br>
<br>
REASON 3. It’s simply not clear. Clever, terse, smart, brilliant, but not clear.<br>
<br>
Compare to:<br>
<br>
// Obviously only `foo` is captured, and not self:<br>
let foo = self.foo<br>
performClosure { foo }<br>
<br>
My two cents.<br>
Gwendal Roué<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> Le 8 déc. 2015 à 18:01, Paul Cantrell via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> a écrit :<br>
><br>
>> For 'let' properties of classes, it'd be reasonable to propose having closures capture the *property* directly by default in this way instead of capturing ‘self'<br>
><br>
> That would be fantastic.<br>
><br>
> I’ve also wondered whether there’s a tidy way for a closure to be tied to the lifecycle of self, so that when self goes away, the closure goes away too. That’s often the desired behavior. On a casual thinking through, though, it seems like a can of worms — and the “guard let self = self else { return }” proposal on another thread gives most of the same benefit.<br>
><br>
> P<br>
><br>
> _______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<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/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>