I get that :) but I think it would be helpful to go beyond the no-op case
and help solve the "strongify" situation that exists in the larger problem
domain.
The "strongify" issue – to me – is mostly about avoiding the need to rename
the captured var in the block to allow for the reference to become a strong
reference. I feel it would be great to tackle that for more then the no-op
case.
In my experience I have had what once was "a simple no-op on nil case" turn
into "if nil do some book keeping and no-op the rest" often enough to
desire a broader solution.
···
On Fri, Feb 19, 2016 at 2:03 PM Kurt Werle <kurt@circlew.org> wrote:
On Fri, Feb 19, 2016 at 1:39 PM, Shawn Erickson via swift-evolution < > swift-evolution@swift.org> wrote:
For example [guard self] capture option supports one specific situation
without the ability of the block to take alternate actions in the situation
of weak self being nil and also requiring no return blocks. This is great
obviously for that particular situation however it doesn't really help with
the other situations.That's the beauty of it. If you want to do something else, this isn't
what you want. This is just a simple bit of sugar to get rid of the very
common use case where you have a nilable/void callback that you only want
executed if self is not nil.If you want/need to do something more complicated, then
{ [unowned self] in
guard self != nil else {
Do the other thing
}
}
is great. It's not boilerplate because you're doing something useful in
the else case.I do still prefer the [unowned self]? syntax, though. It feels so similar
to object?.doSomething(). If the lvalue is nil, you get nothing!Kurt
--
kurt@CircleW.org
Welcome to circlew.org