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

Paul Cantrell cantrell at pobox.com
Wed Jan 6 15:18:41 CST 2016


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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20160106/5ac3aa2f/attachment.html>


More information about the swift-evolution mailing list