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 .succeede
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
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, J
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
>
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 backt
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 con
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
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.
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
> com
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 aft
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
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 `se
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 1
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 p
+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
g
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. vi
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
17 matches
Mail list logo
