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

[Patrick Smith via swift-evolution]

How about [weak(guard) self]? It would only work with closures returning -> () 
as if you are weakly capturing something you are likely to be messaging that 
not returning some, so they can be ignored.

networkRequest.fetchData() { [weak(guard) self] result in
switch result {
case .succeeded(let data):
self.processData(data)

case .failed(let err):
self.handleError(err)
}
}

Patrick


> On 13 May 2016, at 2:10 AM, Hoon H. via swift-evolution 
>  wrote:
> 
> I am replying months lately, but anyway, I just read your proposal, and I 
> think this is cool.
> 
>[guard self]
> 
> I am in doubt about another stuffs such as `[guard self else …]`. I hope your 
> proposal to be accepted. I am getting a bit tired of writing `guard let S = 
> self else { … }`.
> 
> I am still not sure how to use mailing list… but I hope this to be a correct 
> way.
> …Sending again because I mistyped Evan’s address.
> 
> — Hoon H.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Hoon H. via swift-evolution]

I am replying months lately, but anyway, I just read your proposal, and I think 
this is cool.

[guard self]

I am in doubt about another stuffs such as `[guard self else …]`. I hope your 
proposal to be accepted. I am getting a bit tired of writing `guard let S = 
self else { … }`.

I am still not sure how to use mailing list… but I hope this to be a correct 
way.
…Sending again because I mistyped Evan’s address.

— Hoon H.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Paul Cantrell via swift-evolution]

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 
>  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  > 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 
>> > 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 >> > 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 >> > 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 
 > 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 
 > 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@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
> 
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Alex Johnson via swift-evolution]

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@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@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  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@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 
>> 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  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@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 <
>>> christorog...@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>


-- 

*Alex Johnson | Engineering Lead*

*Quick Left, Inc. *
*Boulder **|* *Denver* *|* *Portland** |** San Francisco*

1 (844) QL-NERDS

@nonsensery


 
 
 


*What's it like to work with us? **TrainingPeaks, iTriage, and Ping
Identity share their stories in this short video** A 

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

[Paul Cantrell via swift-evolution]

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 
>  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 > > 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 > > 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 
>>> > 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 >> > 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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

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  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@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 
> 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  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@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 <
>> christorog...@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

Perhaps I was being too imprecise; I meant that *rebinding* self isn't
currently allowed. Incidentally, this is exactly what the proposal is
proposing to allow.

Jacob

On Wed, Jan 6, 2016 at 1:18 PM, Paul Cantrell  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@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  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@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 
>> 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  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@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 <
>>> christorog...@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@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

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 
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 }
> On Wed, Jan 6, 2016 at 10:55 AM Jacob Bandes-Storch via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> FWIW, in a codebase of ~150 Swift files, I see 18 occurrences of "let
>> strongSelf = self", and 26 occurrences of "self?." (which should arguably
>> be changed to the former).
>>
>> Jacob
>>
>> On Tue, Jan 5, 2016 at 5:46 PM, Jacob Bandes-Storch 
>> wrote:
>>
>>> +1.
>>>
>>> Merely using "self?.something" repeatedly might produce unexpected
>>> behavior, if self becomes nil between calls. As I mentioned in another
>>> thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).
>>>
>>> In many cases, I use the pattern
>>>
>>> somethingAsync { [weak self] in
>>> guard let strongSelf = self else { return }
>>>
>>> // use strongSelf below
>>> }
>>>
>>> But of course, this leads to the unnatural/unwieldy
>>> "strongSelf.property" all over the place.
>>>
>>> I agree with Jordan that "guard let self = self" isn't the most
>>> satisfying syntax, but it has the advantage of being a *very* minimal
>>> grammar/syntax change, and its behavior is completely clear as long as the
>>> user is already familiar with guard.
>>>
>>> We should also consider whether "self." is required after "guard let
>>> self = self". An explicit "guard let self = self" avoids the
>>> accidental-capture problem, so I think it's reasonable to allow unqualified
>>> property access for the remainder of the scope.
>>>
>>> Jacob
>>>
>>> On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
 This has come up before, in a thread called "Proposal: weakStrong self
 in completion handler closures". I'm still not 100% happy with the
 syntax, but I like that "guard let" can handle non-Void non-Optional
 returns well, while 'weakStrong' cannot.

 Jordan


 On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
 swift-evolution@swift.org> wrote:

 Currently, weakly captured `self` cannot be bound to `guard let …` with
 same name, and emits a compiler error.

 class Foo {
 func test2(f: ()->()) {
 // …
 }
 func test1() {
 test2 { [weak self] in
 guard let self = self else { return } // Error.
 print(self)
 }
 }
 }

 Do we have any reason to disallow making `self` back to strong
 reference? It’d be nice if I can do it. Please consider this case.

 class Foo {
 func getValue1() -> Int {
 return 1234
 }
 func test3(value: Int) {
 print(value)
 }
 func test2(f: ()->()) {
 // …
 }
 func test1() {
 test2 { [weak self] in
 self?.test3(self?.getValue1()) // Doesn't work because it's not
 unwrapped.

 self!.test3(self!.getValue1()) // Considered harmful due to `!`.

 guard self != nil else { return }
 self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.

 guard let self1 = self else { return }
 self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
 new name `self1`.

 guard let self = self else { return }
 self.test3(self.getValue1()) // OK.

 }
 }
 }

 This also can be applied to `if let` or same sort of constructs.

 Even further, we can consider removing required reference to `self`
 after `guard let …` if appropriate.

 guard let self = self else { return }
 test3(getValue1()) // Referencing to `self` would not be required
 anymore. Seems arguable.

 I think this is almost fine because users have to express their
 intention explicitly with `guard` statement. If someone erases the `guard`
 later, compiler will require explicit self again, and that will prevent
 mistakes. But still, I am not sure this removal would be perfectly fine.

 I am not sure whether this is already supported or planned. But lacked
 at least in Swift 2.1.1.

 — Hoon H.















 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution



 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution


>>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> 

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

[Kevin Ballard via swift-evolution]

I actually expected it to create a different identifier that is
unrelated to the keyword, so you can refer to `self` with backticks in
the future to get the version bound by the guard, and self as a keyword
to get the original value of self.

Not that I think this is particularly useful, of course...

-Kevin Ballard

On Tue, Jan 5, 2016, at 08:42 PM, Greg Parker via swift-evolution 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
>>  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
>>  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
  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
  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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Greg Parker via swift-evolution]

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 
>  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  > 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@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Christopher Rogers via swift-evolution]

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 }
On Wed, Jan 6, 2016 at 10:55 AM Jacob Bandes-Storch via swift-evolution <
swift-evolution@swift.org> wrote:

> FWIW, in a codebase of ~150 Swift files, I see 18 occurrences of "let
> strongSelf = self", and 26 occurrences of "self?." (which should arguably
> be changed to the former).
>
> Jacob
>
> On Tue, Jan 5, 2016 at 5:46 PM, Jacob Bandes-Storch 
> wrote:
>
>> +1.
>>
>> Merely using "self?.something" repeatedly might produce unexpected
>> behavior, if self becomes nil between calls. As I mentioned in another
>> thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).
>>
>> In many cases, I use the pattern
>>
>> somethingAsync { [weak self] in
>> guard let strongSelf = self else { return }
>>
>> // use strongSelf below
>> }
>>
>> But of course, this leads to the unnatural/unwieldy "strongSelf.property"
>> all over the place.
>>
>> I agree with Jordan that "guard let self = self" isn't the most
>> satisfying syntax, but it has the advantage of being a *very* minimal
>> grammar/syntax change, and its behavior is completely clear as long as the
>> user is already familiar with guard.
>>
>> We should also consider whether "self." is required after "guard let self
>> = self". An explicit "guard let self = self" avoids the accidental-capture
>> problem, so I think it's reasonable to allow unqualified property access
>> for the remainder of the scope.
>>
>> Jacob
>>
>> On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>>> This has come up before, in a thread called "Proposal: weakStrong self
>>> in completion handler closures". I'm still not 100% happy with the
>>> syntax, but I like that "guard let" can handle non-Void non-Optional
>>> returns well, while 'weakStrong' cannot.
>>>
>>> Jordan
>>>
>>>
>>> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
>>> swift-evolution@swift.org> wrote:
>>>
>>> Currently, weakly captured `self` cannot be bound to `guard let …` with
>>> same name, and emits a compiler error.
>>>
>>> class Foo {
>>> func test2(f: ()->()) {
>>> // …
>>> }
>>> func test1() {
>>> test2 { [weak self] in
>>> guard let self = self else { return } // Error.
>>> print(self)
>>> }
>>> }
>>> }
>>>
>>> Do we have any reason to disallow making `self` back to strong
>>> reference? It’d be nice if I can do it. Please consider this case.
>>>
>>> class Foo {
>>> func getValue1() -> Int {
>>> return 1234
>>> }
>>> func test3(value: Int) {
>>> print(value)
>>> }
>>> func test2(f: ()->()) {
>>> // …
>>> }
>>> func test1() {
>>> test2 { [weak self] in
>>> self?.test3(self?.getValue1()) // Doesn't work because it's not
>>> unwrapped.
>>>
>>> self!.test3(self!.getValue1()) // Considered harmful due to `!`.
>>>
>>> guard self != nil else { return }
>>> self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.
>>>
>>> guard let self1 = self else { return }
>>> self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
>>> new name `self1`.
>>>
>>> guard let self = self else { return }
>>> self.test3(self.getValue1()) // OK.
>>>
>>> }
>>> }
>>> }
>>>
>>> This also can be applied to `if let` or same sort of constructs.
>>>
>>> Even further, we can consider removing required reference to `self`
>>> after `guard let …` if appropriate.
>>>
>>> guard let self = self else { return }
>>> test3(getValue1()) // Referencing to `self` would not be required
>>> anymore. Seems arguable.
>>>
>>> I think this is almost fine because users have to express their
>>> intention explicitly with `guard` statement. If someone erases the `guard`
>>> later, compiler will require explicit self again, and that will prevent
>>> mistakes. But still, I am not sure this removal would be perfectly fine.
>>>
>>> I am not sure whether this is already supported or planned. But lacked
>>> at least in Swift 2.1.1.
>>>
>>> — Hoon H.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>>
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>
>>>
>>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jordan Rose via swift-evolution]

This has come up before, in a thread called "Proposal: weakStrong self in 
completion handler closures". I'm still not 100% happy with the syntax, but I 
like that "guard let" can handle non-Void non-Optional returns well, while 
'weakStrong' cannot.

Jordan


> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution 
>  wrote:
> 
> Currently, weakly captured `self` cannot be bound to `guard let …` with same 
> name, and emits a compiler error.
> 
>   class Foo {
>   func test2(f: ()->()) {
>   // … 
>   }
>   func test1() {
>   test2 { [weak self] in
>   guard let self = self else { return } // Error.
>   print(self)
>   }
>   }
>   }
> 
> Do we have any reason to disallow making `self` back to strong reference? 
> It’d be nice if I can do it. Please consider this case.
> 
>   class Foo {
>   func getValue1() -> Int {
>   return 1234
>   }
>   func test3(value: Int) {
>   print(value)
>   }
>   func test2(f: ()->()) {
>   // … 
>   }
>   func test1() {
>   test2 { [weak self] in
>   self?.test3(self?.getValue1()) // Doesn't work 
> because it's not unwrapped.
> 
>   self!.test3(self!.getValue1()) // Considered 
> harmful due to `!`.
> 
>   guard self != nil else { return }
>   self!.test3(self!.getValue1()) // OK, but still 
> looks and feels harmful.
> 
>   guard let self1 = self else { return }
>   self1.test3(self1.getValue1()) // OK, but feels 
> ugly due to unnecessary new name `self1`.
> 
>   guard let self = self else { return }
>   self.test3(self.getValue1()) // OK.
> 
>   }
>   }
>   }
> 
> This also can be applied to `if let` or same sort of constructs.
> 
> Even further, we can consider removing required reference to `self` after 
> `guard let …` if appropriate.
> 
>   guard let self = self else { return } 
>   test3(getValue1()) // Referencing to `self` would not be required 
> anymore. Seems arguable.
> 
> I think this is almost fine because users have to express their intention 
> explicitly with `guard` statement. If someone erases the `guard` later, 
> compiler will require explicit self again, and that will prevent mistakes. 
> But still, I am not sure this removal would be perfectly fine.
> 
> I am not sure whether this is already supported or planned. But lacked at 
> least in Swift 2.1.1.
> 
> — Hoon H.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

+1.

Merely using "self?.something" repeatedly might produce unexpected
behavior, if self becomes nil between calls. As I mentioned in another
thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).

In many cases, I use the pattern

somethingAsync { [weak self] in
guard let strongSelf = self else { return }

// use strongSelf below
}

But of course, this leads to the unnatural/unwieldy "strongSelf.property"
all over the place.

I agree with Jordan that "guard let self = self" isn't the most satisfying
syntax, but it has the advantage of being a *very* minimal grammar/syntax
change, and its behavior is completely clear as long as the user is already
familiar with guard.

We should also consider whether "self." is required after "guard let self =
self". An explicit "guard let self = self" avoids the accidental-capture
problem, so I think it's reasonable to allow unqualified property access
for the remainder of the scope.

Jacob

On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
swift-evolution@swift.org> wrote:

> This has come up before, in a thread called "Proposal: weakStrong self in
> completion handler closures". I'm still not 100% happy with the syntax,
> but I like that "guard let" can handle non-Void non-Optional returns well,
> while 'weakStrong' cannot.
>
> Jordan
>
>
> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> Currently, weakly captured `self` cannot be bound to `guard let …` with
> same name, and emits a compiler error.
>
> class Foo {
> func test2(f: ()->()) {
> // …
> }
> func test1() {
> test2 { [weak self] in
> guard let self = self else { return } // Error.
> print(self)
> }
> }
> }
>
> Do we have any reason to disallow making `self` back to strong reference?
> It’d be nice if I can do it. Please consider this case.
>
> class Foo {
> func getValue1() -> Int {
> return 1234
> }
> func test3(value: Int) {
> print(value)
> }
> func test2(f: ()->()) {
> // …
> }
> func test1() {
> test2 { [weak self] in
> self?.test3(self?.getValue1()) // Doesn't work because it's not unwrapped.
>
> self!.test3(self!.getValue1()) // Considered harmful due to `!`.
>
> guard self != nil else { return }
> self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.
>
> guard let self1 = self else { return }
> self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
> new name `self1`.
>
> guard let self = self else { return }
> self.test3(self.getValue1()) // OK.
>
> }
> }
> }
>
> This also can be applied to `if let` or same sort of constructs.
>
> Even further, we can consider removing required reference to `self` after
> `guard let …` if appropriate.
>
> guard let self = self else { return }
> test3(getValue1()) // Referencing to `self` would not be required anymore.
> Seems arguable.
>
> I think this is almost fine because users have to express their intention
> explicitly with `guard` statement. If someone erases the `guard` later,
> compiler will require explicit self again, and that will prevent mistakes.
> But still, I am not sure this removal would be perfectly fine.
>
> I am not sure whether this is already supported or planned. But lacked at
> least in Swift 2.1.1.
>
> — Hoon H.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Jacob Bandes-Storch via swift-evolution]

FWIW, in a codebase of ~150 Swift files, I see 18 occurrences of "let
strongSelf = self", and 26 occurrences of "self?." (which should arguably
be changed to the former).

Jacob

On Tue, Jan 5, 2016 at 5:46 PM, Jacob Bandes-Storch 
wrote:

> +1.
>
> Merely using "self?.something" repeatedly might produce unexpected
> behavior, if self becomes nil between calls. As I mentioned in another
> thread, in Obj-C, there is a warning for this (-Warc-repeated-use-of-weak).
>
> In many cases, I use the pattern
>
> somethingAsync { [weak self] in
> guard let strongSelf = self else { return }
>
> // use strongSelf below
> }
>
> But of course, this leads to the unnatural/unwieldy "strongSelf.property"
> all over the place.
>
> I agree with Jordan that "guard let self = self" isn't the most satisfying
> syntax, but it has the advantage of being a *very* minimal grammar/syntax
> change, and its behavior is completely clear as long as the user is already
> familiar with guard.
>
> We should also consider whether "self." is required after "guard let self
> = self". An explicit "guard let self = self" avoids the accidental-capture
> problem, so I think it's reasonable to allow unqualified property access
> for the remainder of the scope.
>
> Jacob
>
> On Tue, Jan 5, 2016 at 4:20 PM, Jordan Rose via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>> This has come up before, in a thread called "Proposal: weakStrong self
>> in completion handler closures". I'm still not 100% happy with the
>> syntax, but I like that "guard let" can handle non-Void non-Optional
>> returns well, while 'weakStrong' cannot.
>>
>> Jordan
>>
>>
>> On Jan 5, 2016, at 16:02, Hoon H. via swift-evolution <
>> swift-evolution@swift.org> wrote:
>>
>> Currently, weakly captured `self` cannot be bound to `guard let …` with
>> same name, and emits a compiler error.
>>
>> class Foo {
>> func test2(f: ()->()) {
>> // …
>> }
>> func test1() {
>> test2 { [weak self] in
>> guard let self = self else { return } // Error.
>> print(self)
>> }
>> }
>> }
>>
>> Do we have any reason to disallow making `self` back to strong reference?
>> It’d be nice if I can do it. Please consider this case.
>>
>> class Foo {
>> func getValue1() -> Int {
>> return 1234
>> }
>> func test3(value: Int) {
>> print(value)
>> }
>> func test2(f: ()->()) {
>> // …
>> }
>> func test1() {
>> test2 { [weak self] in
>> self?.test3(self?.getValue1()) // Doesn't work because it's not unwrapped.
>>
>> self!.test3(self!.getValue1()) // Considered harmful due to `!`.
>>
>> guard self != nil else { return }
>> self!.test3(self!.getValue1()) // OK, but still looks and feels harmful.
>>
>> guard let self1 = self else { return }
>> self1.test3(self1.getValue1()) // OK, but feels ugly due to unnecessary
>> new name `self1`.
>>
>> guard let self = self else { return }
>> self.test3(self.getValue1()) // OK.
>>
>> }
>> }
>> }
>>
>> This also can be applied to `if let` or same sort of constructs.
>>
>> Even further, we can consider removing required reference to `self` after
>> `guard let …` if appropriate.
>>
>> guard let self = self else { return }
>> test3(getValue1()) // Referencing to `self` would not be required
>> anymore. Seems arguable.
>>
>> I think this is almost fine because users have to express their intention
>> explicitly with `guard` statement. If someone erases the `guard` later,
>> compiler will require explicit self again, and that will prevent mistakes.
>> But still, I am not sure this removal would be perfectly fine.
>>
>> I am not sure whether this is already supported or planned. But lacked at
>> least in Swift 2.1.1.
>>
>> — Hoon H.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>>
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution