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

[ilya]

As for 1, isn't the compiler allowed to optimize away self.foo call?

More generally. if we have

class X { let const = 4 }

let x = X()
let closure = {  print(x.const) }

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.

Ilya.

On Tue, Dec 8, 2015 at 8:28 PM, Gwendal Roué <swift-evolution at swift.org>
wrote:

> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151208/b2f60007/attachment.html>