> On 9 Jul 2016, at 06:34, Zhao Xin <[email protected]> wrote:
>
> The compiler is not smart enough to treat this as you think, nor it will be
> designed to. According to the documents, it is the developer‘s burden to add
> @noescape or weak or unowned. So I disagree it is a bug.
>
> Zhaoxin
>
> On Sat, Jul 9, 2016 at 7:30 AM, Karl <[email protected]
> <mailto:[email protected]>> wrote:
>
>> On 5 Jul 2016, at 03:47, Zhao Xin <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> No, it is not a bug.
>>
>> For a closure, you have to call self explicitly unless the closure is mark
>> as @noescape. Also, in this situation, self is not unowned, as the closure
>> is not stored, it ran and released. Below, is a situation that you need use
>> unowned self. Here the closure is stored in variable d instead of running
>> and releasing.
>>
>> lazy var d:()->Int = { [unowned self] in
>> return self.a*self.b
>> }
>>
>> Zhaoxin
>
> In this specific case, when you are initialising from a closure, there is no
> need to make the capture of ‘self’ explicit and it’s totally safe for it to
> be unowned. You can’t invoke the closure without going through a valid
> instance, and that instance always owns the closure and never the other way
> around.
>
I know that the compiler doesn’t do this today, but I disagree that it will
never have enough information to make inferences like this. It would simply be
an adaptation of ARC to Swift - you don’t have these kind of attached lazy
closures in Obj-C, so there was never any need for it. They run in the context
of the instance just like a getter would, so they should have the same
properties as a getter (including implicit ‘self’).
In general though, I think we are moving to “property behaviours”, which may
need something like this in general. You would want to use unowned references
in a stored property behaviour object; any retains/releases would be
unnecessary. I’m sure we’ll talk about it more when that gets further along.
Karl
_______________________________________________
swift-users mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-users
