[swift-evolution] Proposal: Closures capture weak by default

[Gwendal Roué]

Oh, and the concerned reader will have noticed another use of a non-mandatory self in the last sample code:

	// Obviously only `foo` is captured, and not self:
	let foo = self.foo
	performClosure { foo }

Gwendal Roué

> Le 8 déc. 2015 à 18:28, Gwendal Roué <gwendal.roue at gmail.com> a écrit :
> 
> I’m really not found at all of having `let` properties captured by closures when used without explicit `self`.
> 
> Three reasons:
> 
> REASON 1. When `self` is not mandatory, then adding self should have no impact whatsoever.
> 
> Why should one add a self that is not mandatory?
> 
> 1. for symmetry (1):
> 
> 	self.foo = other.foo
> 	let delta = self.x - other.x
> 
> 2. for symmetry (2):
> 	
> 	init(a:String, index:Int) {
> 		self.name = name
> 		self.position = index+1	// keep 1-based value for implementation reasons
> 	}
> 
> 3. add your own reasons to use an explicit self even when not required, and I’m sure you did.
> 
> So generally speaking, using self when not mandatory should have no impact on the program at all.
> 
> 
> 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 = …`.
> 
> That’s not good at all.
> 
> 
> REASON 3. It’s simply not clear. Clever, terse, smart, brilliant, but not clear.
> 
> Compare to:
> 
> 	// Obviously only `foo` is captured, and not self:
> 	let foo = self.foo
> 	performClosure { foo }
> 
> My two cents.
> Gwendal Roué
> 
> 
>> Le 8 déc. 2015 à 18:01, Paul Cantrell via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>>> 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'
>> 
>> That would be fantastic.
>> 
>> 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.
>> 
>> P
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>