[swift-evolution] [Proposal] Guarded self in closures

[David Hedbor]

One more thing I'd like to add into the discussion is handling of optional
variables. My assumption is that if I have an optional variable in the
outer scope, it would remain optional in the inner scope, but the way the
draft is worded, it might seem like it would add an implicit guard
statement in that situation. i.e:

   var opt: Bool?
   var closure = ?{
      if opt {}
   }

=>

   var opt: Bool?
   var closure = {
      guard let opt = opt else { return }
      if opt {}
   }

What are your thoughts on this?

David


On Wed, Feb 22, 2017 at 1:40 PM, Matthew Johnson <matthew at anandabits.com>
wrote:

>
> On Feb 22, 2017, at 3:36 PM, David Hedbor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I did read it, but I think I skimmed it a bit too fast. You're correct in
> that it essentially solves the same problem using a different syntax (more
> compact at that). I think when I initially read it, I parsed it as the
> method would return at any point if the objects were freed (mid-execution
> of the closure). Re-reading it, I see that the proposal is in fact
> identical in functionality to mine, just with a different syntax.
>
> Given that your proposal still allows for overriding the behavior on an
> individual basis, the same thing can be accomplished. I'll put my support
> behind your draft, rather than expending more time with mine. :)
>
>
> Thanks David, glad to hear it!
>
>
> Cheers,
>
> David
>
>
> On Wed, Feb 22, 2017 at 12:57 PM, Matthew Johnson <matthew at anandabits.com>
> 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.  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 at 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 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/20170222/a5ed2691/attachment.html>