I like Kenny and Kurt's points about handling the majority case and keeping
the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a
completion block which returns void. Can we just handle that case and get
rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak
should be in there so it's much more obvious you are doing the weak/strong
dance with self, otherwise it looks like you are guarding against a regular
optional being nil.
I had trouble parsing, too, for some reason. In fact, that is what his
amended proposal states - the else part is to be dropped.
I like this proposal, though I do wonder if it would be nice to have the
syntax
[unowned self]?
So we could also adapt
func requiresNonNilParameters(some: MyClass!)? -> Whatever
that returns if all the parameters are != nil.
Still, I'd be happy if [guard self] did what is proposed.
···
On Fri, Feb 12, 2016 at 10:28 AM, Jason Gregori via swift-evolution < swift-evolution@swift.org> wrote:
I like Kenny and Kurt's points about handling the majority case and
keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a
completion block which returns void. Can we just handle that case and get
rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak
should be in there so it's much more obvious you are doing the weak/strong
dance with self, otherwise it looks like you are guarding against a regular
optional being nil.
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution <swift-evolution@swift.org> wrote:
I like Kenny and Kurt's points about handling the majority case and keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a completion block which returns void. Can we just handle that case and get rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak should be in there so it's much more obvious you are doing the weak/strong dance with self, otherwise it looks like you are guarding against a regular optional being nil.
I like the idea behind this but I feel like a line inside the block can't
really dictate whether self is captured weakly or not. Unless your saying
put this in the bracket part?
[guard reconstitute self] ? That works for me.
PS: I got here from your blog post, thanks!
···
On Fri, Feb 12, 2016 at 10:34 AM, Erica Sadun <erica@ericasadun.com> wrote:
-- E
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution < > swift-evolution@swift.org> wrote:
I like Kenny and Kurt's points about handling the majority case and
keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a
completion block which returns void. Can we just handle that case and get
rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak
should be in there so it's much more obvious you are doing the weak/strong
dance with self, otherwise it looks like you are guarding against a regular
optional being nil.
+1 to the proposal as it stands, including dropping the "else" or extending
to non-void closures. If they turn out to be a problem, another proposal
could be written for them at a later date.
I don't really like the idea of adding another word in there, either [guard
weak self] or [guard reconstitute self]. To me, [guard self] is another
capture semantics, just like [weak self] and [unowned self], and I find it
easier to remember if I can mentally put it in the set of capture semantics
than if I mentally hang it off of [weak self] as a special case. I don't
think there's any reasonable phrase that will explain exactly what this
does without people having to spend a few minutes reading the manual and
absorbing the information, so I'd rather optimize for conciseness for those
who've done this rather than clarity for those who haven't.
···
On Fri, Feb 12, 2016 at 11:08 AM, Jason Gregori via swift-evolution < swift-evolution@swift.org> wrote:
On Fri, Feb 12, 2016 at 10:34 AM, Erica Sadun <erica@ericasadun.com> > wrote:
How about
guard reconstitute self else { return }
I like the idea behind this but I feel like a line inside the block can't
really dictate whether self is captured weakly or not. Unless your saying
put this in the bracket part?
[guard reconstitute self] ? That works for me.
PS: I got here from your blog post, thanks!
-- E
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution < >> swift-evolution@swift.org> wrote:
I like Kenny and Kurt's points about handling the majority case and
keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a
completion block which returns void. Can we just handle that case and get
rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak
should be in there so it's much more obvious you are doing the weak/strong
dance with self, otherwise it looks like you are guarding against a regular
optional being nil.
I thought it might be handy to control how the guard exits scope, enabling self == nil (as well as any other reconstitutions of a weak variable) failure cases to do reporting, fatalError-ing, etc.
-- E
···
On Feb 12, 2016, at 12:08 PM, Jason Gregori <jasongregori@gmail.com> wrote:
On Fri, Feb 12, 2016 at 10:34 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
How about
guard reconstitute self else { return }
I like the idea behind this but I feel like a line inside the block can't really dictate whether self is captured weakly or not. Unless your saying put this in the bracket part?
[guard reconstitute self] ? That works for me.
PS: I got here from your blog post, thanks!
-- E
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I like Kenny and Kurt's points about handling the majority case and keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a completion block which returns void. Can we just handle that case and get rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak should be in there so it's much more obvious you are doing the weak/strong dance with self, otherwise it looks like you are guarding against a regular optional being nil.
What about dropping "guard"? [reconstitute self] (I'll look in the thesaurus later today).
···
On Feb 12, 2016, at 11:57 AM, Jonathan Tang <jonathan.d.tang@gmail.com> wrote:
+1 to the proposal as it stands, including dropping the "else" or extending to non-void closures. If they turn out to be a problem, another proposal could be written for them at a later date.
I don't really like the idea of adding another word in there, either [guard weak self] or [guard reconstitute self]. To me, [guard self] is another capture semantics, just like [weak self] and [unowned self], and I find it easier to remember if I can mentally put it in the set of capture semantics than if I mentally hang it off of [weak self] as a special case. I don't think there's any reasonable phrase that will explain exactly what this does without people having to spend a few minutes reading the manual and absorbing the information, so I'd rather optimize for conciseness for those who've done this rather than clarity for those who haven't.
On Fri, Feb 12, 2016 at 11:08 AM, Jason Gregori via swift-evolution <swift-evolution@swift.org> wrote:
On Fri, Feb 12, 2016 at 10:34 AM, Erica Sadun <erica@ericasadun.com> wrote:
How about
guard reconstitute self else { return }
I like the idea behind this but I feel like a line inside the block can't really dictate whether self is captured weakly or not. Unless your saying put this in the bracket part?
[guard reconstitute self] ? That works for me.
PS: I got here from your blog post, thanks!
-- E
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution <swift-evolution@swift.org> wrote:
I like Kenny and Kurt's points about handling the majority case and keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a completion block which returns void. Can we just handle that case and get rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak should be in there so it's much more obvious you are doing the weak/strong dance with self, otherwise it looks like you are guarding against a regular optional being nil.
Ah, I see. I think that totally makes sense but I would prefer to have just
one bit to write and not have to do both the [weak self] and the guard
statement.
This is why I keep coming back to [guard weak self]. I want to to make self
weak and I want to guard against it being nil.
···
On Fri, Feb 12, 2016 at 1:31 PM, Erica Sadun <erica@ericasadun.com> wrote:
I thought it might be handy to control how the guard exits scope,
enabling self == nil (as well as any other reconstitutions of a weak
variable) failure cases to do reporting, fatalError-ing, etc.
-- E
On Feb 12, 2016, at 12:08 PM, Jason Gregori <jasongregori@gmail.com> > wrote:
On Fri, Feb 12, 2016 at 10:34 AM, Erica Sadun <erica@ericasadun.com> > wrote:
How about
guard reconstitute self else { return }
I like the idea behind this but I feel like a line inside the block can't
really dictate whether self is captured weakly or not. Unless your saying
put this in the bracket part?
[guard reconstitute self] ? That works for me.
PS: I got here from your blog post, thanks!
-- E
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution < >> swift-evolution@swift.org> wrote:
I like Kenny and Kurt's points about handling the majority case and
keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a
completion block which returns void. Can we just handle that case and get
rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak
should be in there so it's much more obvious you are doing the weak/strong
dance with self, otherwise it looks like you are guarding against a regular
optional being nil.
I think it's important to defer to the programmer on how the weak self condition is handled, enabling any clean-up action to be taken as well as deciding whether to terminate the app, recover, etc.
-- E
···
On Feb 12, 2016, at 3:20 PM, Jason Gregori <jasongregori@gmail.com> wrote:
Ah, I see. I think that totally makes sense but I would prefer to have just one bit to write and not have to do both the [weak self] and the guard statement.
This is why I keep coming back to [guard weak self]. I want to to make self weak and I want to guard against it being nil.
On Fri, Feb 12, 2016 at 1:31 PM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
It would follow
I thought it might be handy to control how the guard exits scope, enabling self == nil (as well as any other reconstitutions of a weak variable) failure cases to do reporting, fatalError-ing, etc.
-- E
On Feb 12, 2016, at 12:08 PM, Jason Gregori <jasongregori@gmail.com <mailto:jasongregori@gmail.com>> wrote:
On Fri, Feb 12, 2016 at 10:34 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:
How about
guard reconstitute self else { return }
I like the idea behind this but I feel like a line inside the block can't really dictate whether self is captured weakly or not. Unless your saying put this in the bracket part?
[guard reconstitute self] ? That works for me.
PS: I got here from your blog post, thanks!
-- E
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I like Kenny and Kurt's points about handling the majority case and keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a completion block which returns void. Can we just handle that case and get rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think weak should be in there so it's much more obvious you are doing the weak/strong dance with self, otherwise it looks like you are guarding against a regular optional being nil.
No strong objection, although I like "guard" because it implies that the
first statement in the closure is an implicit guard on the value captured.
···
On Fri, Feb 12, 2016 at 12:08 PM, Jason Gregori <jasongregori@gmail.com> wrote:
What about dropping "guard"? [reconstitute self] (I'll look in the
thesaurus later today).
On Feb 12, 2016, at 11:57 AM, Jonathan Tang <jonathan.d.tang@gmail.com> > wrote:
+1 to the proposal as it stands, including dropping the "else" or
extending to non-void closures. If they turn out to be a problem, another
proposal could be written for them at a later date.
I don't really like the idea of adding another word in there, either
[guard weak self] or [guard reconstitute self]. To me, [guard self] is
another capture semantics, just like [weak self] and [unowned self], and I
find it easier to remember if I can mentally put it in the set of capture
semantics than if I mentally hang it off of [weak self] as a special case.
I don't think there's any reasonable phrase that will explain exactly what
this does without people having to spend a few minutes reading the manual
and absorbing the information, so I'd rather optimize for conciseness for
those who've done this rather than clarity for those who haven't.
On Fri, Feb 12, 2016 at 11:08 AM, Jason Gregori via swift-evolution < > swift-evolution@swift.org> wrote:
On Fri, Feb 12, 2016 at 10:34 AM, Erica Sadun <erica@ericasadun.com> >> wrote:
How about
guard reconstitute self else { return }
I like the idea behind this but I feel like a line inside the block can't
really dictate whether self is captured weakly or not. Unless your saying
put this in the bracket part?
[guard reconstitute self] ? That works for me.
PS: I got here from your blog post, thanks!
-- E
On Feb 12, 2016, at 11:28 AM, Jason Gregori via swift-evolution < >>> swift-evolution@swift.org> wrote:
I like Kenny and Kurt's points about handling the majority case and
keeping the syntax simpler.
I feel like most of the time I want to break a retain cycle is for a
completion block which returns void. Can we just handle that case and get
rid of the else?
Also, I don't think [guard self] is self explanatory enough. I think
weak should be in there so it's much more obvious you are doing the
weak/strong dance with self, otherwise it looks like you are guarding
against a regular optional being nil.