> On Feb 22, 2017, at 5:06 PM, Anton Mironov <antonvmiro...@gmail.com> wrote:
>
> -1
> I support improvements in this area but I do not think that adding guarded
> closures will fix the case.
> It raises multiple concerns:
> - prepending ? to the closure declaration is as forgettable as `[weak self]`
No, this is why I included the `@guarded` parameter annotation. This allows an
API to require its callers to use a guarded closure. Strong references would
have to be explicit in the capture list.
> - reactive programming often assumes chaining of operations. How guarded
> closures affect next operations in the chain?
Can you provide a concrete example of real world code you wrote manually? I
will convert it to use guarded closures to show how it is affected.
> - the closure must exist until either the control deallocates (source of
> actions) or self deallocates (destination of actions). Guarded closure will
> not provide an expected behavior
Yes they will. The guarded closure lives until the control releases it. But
it becomes a no-op if any of the references captured with a guard are released
before that happens. This is much like the behavior of the target / action
pattern but generalized to support closures.
> - managing lifecycle of nested guarded closures could be complex to
> understand and implement into the language
I’m glad you brought this up. I’ll give it some thought. If there does turn
out to be complexity involved I wouldn’t have a problem prohibiting that.
> - why would you consider using @escaping instead of @guarded?
Because sometimes the right default for a function taking an escaping closure
is a strong reference. I wouldn't want `DispatchQueue.async` to take a guarded
closure. That API doesn’t contain any semantic content around *why* you
dispatched async. It’s not a callback, but instead a way of moving work around.
>
> I personally prefer doing something like this:
>
> ```swift
> self.button.onAction(forEvents: [.touchUpInside], context: self) { (self,
> sender, event) in
> self.performSearch(query: self.searchField.text)
> }
> ```
>
> or
>
> ```swift
> self.button.actions(forEvents: [.touchUpInside])
> .debounce(interval: 3.0)
> .map(context: self) { (self, _) in
> return self.searchField.text
> }
> .distinct()
> .onUpdate(context: self) { (self, searchQuery) in
> self.performSearch(query: searchQuery)
> }
> ```
>
> This code neither requires an addition of language features nor contains
> retain cycles. All closures will be released as soon as source or destination
> deallocates.
This isn’t too bad but it does require manually threading the context. This is
more work for both the library and the client than necessary. It also does not
help users avoid an accidental strong reference in the closure. It nudges them
not to by offering to thread the context but it doesn’t do anything to prevent
it. You can still create a strong reference (event to self) without specifying
it in the capture list.
I think there is a place for a language solution here.
>
>> On Feb 22, 2017, at 22:57, Matthew Johnson via swift-evolution
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>
>> Hi David,
>>
>> I just shared a draft proposal to introduce guarded closures last week:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html
>>
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170213/032478.html>.
>> I think you would find it very interesting.
>>
>> I considered including a new capture list specifier `guard` in this proposal
>> but decided against it. Guarded behavior requires prefixing the contents of
>> the closure with a guard clause that returns immediately if the guard is
>> tripped. This is a property of the closure as a whole, not of an individual
>> capture. For that reason, I decided that allowing a `guard` specifier for
>> an individual capture would be inappropriate.
>>
>> Instead, a guarded closure has a guarded by default capture behavior which
>> can be overridden with `weak`, `unowned` or `strong` in the capture list.
>> The thread on this proposal was relatively brief. I plan to open a PR soon
>> after making a few minor modifications.
>>
>> Matthew
>>
>>> On Feb 22, 2017, at 2:48 PM, David Hedbor via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>> Hello,
>>>
>>> (apologies if this got sent twice - gmail and Apple mail seems to confused
>>> as to what account the first mail was sent from)
>>>
>>> I’m new to this mailing list, but have read some archived messages, and
>>> felt that this would be a reasonable subject to discuss. It’s somewhat
>>> related to the recent posts about @selfsafae/@guarded but distinctly
>>> different regardless.
>>>
>>>
>>> Problem:
>>>
>>> It’s often desirable not to capture self in closures, but the syntax for
>>> doing so adds significant boilerplate code for [weak self] or us unsafe
>>> when used with [unowned self]. Typically you’d do something like this:
>>>
>>> { [weak self] in self?.execute() }
>>>
>>> This is simple enough but often doesn’t work:
>>>
>>> { [weak self] in self?.boolean = self?.calculateBoolean() ]
>>>
>>> This fails because boolean is not an optional. This in turn leads to code
>>> like this:
>>>
>>> { [weak self] in
>>> guard let strongSelf = self else { return }
>>> strongSelf.boolean = self.calculateBoolean() }
>>>
>>> And this is the boilerplate code. My suggestion is to add a syntax that
>>> works the same as the third syntax, yet doesn’t require the boilerplate
>>> code.
>>>
>>>
>>> Solution:
>>>
>>> Instead of using unowned or weak, let’s use guard/guarded syntax:
>>>
>>>
>>> { [guard self] in
>>> self.isExecuted = self.onlyIfWeakSelfWasCaptured()
>>> }
>>>
>>> In essence, guarded self is equivalent to a weak self, that’s captured when
>>> the closure is executed. If it was already released at that point, the
>>> closure is simply not executed. It’s equivalent to:
>>>
>>> { [weak self] in
>>> guard let strongSelf = self else { return }
>>> strongSelf.isExecuted = strongSelf.onlyIfWeakSelfWasCaptured()
>>> }
>>>
>>> Except with a lot less boilerplate code, while not losing any clarify in
>>> what it does.
>>>
>>> Impact / compatibility:
>>>
>>> This is simply additive syntax, and wouldn’t affect any existing code.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
