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

[Gwendal Roué]

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