# `@selfsafe`: a new way to avoid reference cycles
* Proposal: [SE-](-selfsafe.md)
* Authors: [Matthew Johnson](https://github.com/anandabits)
* Review Manager: TBD
* Status: **Awaiting review**
## Introduction
This proposal introduces the `@selfsafe` function argument attribute which
t
> On Feb 20, 2017, at 12:20 AM, David Hart wrote:
>
>
> On 20 Feb 2017, at 06:05, Brent Royal-Gordon via swift-evolution
> wrote:
>
>>> On Feb 19, 2017, at 7:06 PM, Matthew Johnson wrote:
>>>
>>> Often you hand it to something owned by self, but it's also the case that
>>> you often hand
> On 20 Feb 2017, at 16:02, Matthew Johnson wrote:
>
>
>> On Feb 20, 2017, at 12:20 AM, David Hart wrote:
>>
>>
>> On 20 Feb 2017, at 06:05, Brent Royal-Gordon via swift-evolution
>> wrote:
>>
On Feb 19, 2017, at 7:06 PM, Matthew Johnson
wrote:
Often you hand it to
This reminded me of an idea I had long time ago which will have a similar
effect: add a way to disable implicit captures for closures. FWIW.
> On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution
> wrote:
>
> # `@selfsafe`: a new way to avoid reference cycles
>
> * Proposal: [SE-N
What wrong with [unowned self]
On Sat, Feb 18, 2017 at 11:01 PM Daniel Duan via swift-evolution <
swift-evolution@swift.org> wrote:
> This reminded me of an idea I had long time ago which will have a similar
> effect: add a way to disable implicit captures for closures. FWIW.
>
> > On Feb 18, 2017
> On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution
> wrote:
>
> This proposal introduces the `@selfsafe` function argument attribute which
> together with a `withWeakSelf` property on values of function type. Together
> these features enable library authors to create APIs can
This places the burden on users. The library is not able to offer a guarantee.
Sent from my iPad
> On Feb 19, 2017, at 1:20 AM, Derrick Ho wrote:
>
> What wrong with [unowned self]
>> On Sat, Feb 18, 2017 at 11:01 PM Daniel Duan via swift-evolution
>> wrote:
>> This reminded me of an idea I
I must admit I find this proposal very weird.
• it only handles strong references to self. While the APIs we work with mostly
direct us towards accidental references cycles including self in closures, I
would want a compiler feature to be much more generic.
• I'm not a fan of "magically" fixing
Sent from my iPad
On Feb 19, 2017, at 2:15 AM, Brent Royal-Gordon wrote:
>> On Feb 18, 2017, at 5:24 PM, Matthew Johnson via swift-evolution
>> wrote:
>>
>> This proposal introduces the `@selfsafe` function argument attribute which
>> together with a `withWeakSelf` property on values of fu
Sent from my iPad
> On Feb 19, 2017, at 7:41 AM, David Hart wrote:
>
> I must admit I find this proposal very weird.
I am going to remove the `withWeakSelf` property. This conversion can be
handled behind the scenes as an implementation detail of passing an argument to
a parameter that inc
Hi Matthew,
I'm not convinced we should come with a new mechanism that would handle the
capture of `self` differently from the other captures. I do understand that
this would match the way Apple APIs work, but as a general purpose language,
this looks weird to add some asymmetry in the language
Thanks for reply Mathew. Here are some more comments:
> On 19 Feb 2017, at 15:51, Matthew Johnson wrote:
>
>
>
> Sent from my iPad
>
>> On Feb 19, 2017, at 7:41 AM, David Hart wrote:
>>
>> I must admit I find this proposal very weird.
>
> I am going to remove the `withWeakSelf` property.
> On Feb 19, 2017, at 6:45 AM, Matthew Johnson wrote:
>
> 1. Swift *already* acknowledges that it is far easier to create a reference
> cycle through captured strong references to `self` than any other way. This
> is why you have to explicitly say `self.` in escaping closures.
The reason you
Sent from my iPad
On Feb 19, 2017, at 6:30 PM, Brent Royal-Gordon wrote:
>> On Feb 19, 2017, at 6:45 AM, Matthew Johnson wrote:
>>
>> 1. Swift *already* acknowledges that it is far easier to create a reference
>> cycle through captured strong references to `self` than any other way. This
> On Feb 19, 2017, at 7:06 PM, Matthew Johnson wrote:
>
> Often you hand it to something owned by self, but it's also the case that you
> often hand it to something not owned by self, but that should not extend the
> lifetime of self.
I don't agree that it shouldn't extend the lifetime of `sel
On 20 Feb 2017, at 06:05, Brent Royal-Gordon via swift-evolution
wrote:
>> On Feb 19, 2017, at 7:06 PM, Matthew Johnson wrote:
>>
>> Often you hand it to something owned by self, but it's also the case that
>> you often hand it to something not owned by self, but that should not extend
>> t
16 matches
Mail list logo