[swift-evolution] Allowing `guard let self = self else { ... }` for weakly captured self in a closure.

[Alex Johnson]

Escaping self with back-ticks is an intriguing workaround for this.
However, I think escaping keywords with back-ticks for anything other than
avoiding interop naming issues should be considered an antipattern.

Allowing "guard let self = self else { return }" makes a lot of sense to me.

On Wed, Jan 6, 2016 at 1:18 PM, Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

> But “self” _is_ a reserved word, and that’s the whole reason that this
> proposal is necessary in the first place. If “self” were just a normal
> identifier, then “if let self = self” would work just as well as “if let
> foo = foo” and there would be nothing to discuss.
>
> The docs also say "The backticks are not considered part of the
> identifier; `x` and x have the same meaning." Thus `self` and self should
> have the same meaning.
>
>
> Well, `flurtzle` and flurtzle would have the same meaning, but `self` is
> an identifier whereas as self is a keyword, so they mean different things.
> That is precisely what the backticks are for.
>
> Assigning to `self` is the same as assigning to self, which intentionally
> isn't allowed.
>
>
> No, you’re creating a new identifier called “self” which shadows the old
> one.
>
> Consider this:
>
>     let foo: Int? = 7
>     if let foo = foo {
>         print(foo + 1)
>     }
>
> There are two identifiers named foo, one optional, one not. Both are
> declared with “let”, so neither can be assigned to. But the code works.
> Why? Because “let foo = foo” doesn’t assign to the outer variable; it
> creates a new one. If self were not a keyword, then it would work the same
> as “foo” above.
>
> Cheers,
>
> Paul
>
>
> On Jan 6, 2016, at 2:56 PM, Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Not exactly; backticks are for making an identifier out of something
> that's not normally an identifier. Most other reserved words are used in
> control flow & other declarations. Rarely do they actually represent
> identifiers/values that you can work with.
>
> The docs also say "The backticks are not considered part of the
> identifier; `x` and x have the same meaning." Thus `self` and self should
> have the same meaning. Assigning to `self` is the same as assigning to
> self, which intentionally isn't allowed. Backticks shouldn't allow you to
> circumvent that.
>
> Jacob
>
> On Wed, Jan 6, 2016 at 12:50 PM, Paul Cantrell <paul at innig.net> wrote:
>
>> Ummm … isn’t that _exactly_ what backticks are for? From the docs:
>>
>>     To use a reserved word as an identifier, put a backtick (`) before
>> and after it.
>>
>>
>> On Jan 5, 2016, at 10:42 PM, Greg Parker via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>> I think it is a bug  :-)  That's not what backquotes are for. It ought to
>> be either supported without the backquotes or banned regardless of
>> backquotes.
>>
>> On Jan 5, 2016, at 8:34 PM, Jacob Bandes-Storch <jtbandes at gmail.com>
>> wrote:
>>
>> Yes, it seems to use the strong shadowing variable. (The compiler doesn't
>> complain about "self.foo", and "self?.foo" becomes invalid because self is
>> no longer optional.)
>>
>> If it weren't so useful, I'd call it a bug.
>>
>> On Tue, Jan 5, 2016 at 8:34 PM, Greg Parker <gparker at apple.com> wrote:
>>
>>> Does further use of self after that actually use a strong shadowing
>>> variable? Or does it go back to the weak reference it already had as if the
>>> shadow were not there?
>>>
>>> On Jan 5, 2016, at 8:26 PM, Jacob Bandes-Storch via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> Wow! I didn't know that worked. It's a bit surprising, and perhaps not
>>> intended. I think the proposal is still valid.
>>>
>>> On Tue, Jan 5, 2016 at 8:21 PM, Christopher Rogers <
>>> christorogers at gmail.com> wrote:
>>>
>>>> You can shadow self with a guard like you wrote it if use the keyword
>>>> escaping backquotes like so:
>>>>
>>>> guard let `self` = self else { return }
>>>
>>>
>> _______________________________________________
>> 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
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 

*Alex Johnson | Engineering Lead*

*Quick Left, Inc. <https://quickleft.com/>*
*Boulder **|* *Denver* *|* *Portland** |** San Francisco*

1 (844) QL-NERDS

@nonsensery


<https://github.com/quickleft> <https://www.facebook.com/quickleft>
<https://twitter.com/quickleft> <https://instagram.com/quick_left/>
<https://www.flickr.com/photos/quickleft> <https://vimeo.com/quickleft>


*What's it like to work with us? **TrainingPeaks, iTriage, and Ping
Identity share their stories in this short video** A Client's View
<https://vimeo.com/92286352>*.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160106/5c541f7b/attachment.html>