Guard let

Evolution Discussion
1

First time trying to contribute, hopefully this is the proper channel to submit.

I propose an addition to the guard let statement to allow for replacement of optionals with unwrapped values.

ex)

two current options

obj.methodWithCallback() {(foo, bar) in
  guard let foo = foo else {
    return
  }
  
  foo.prop = “new”
}

OR

obj.methodWithCallback() {(foo, bar) in
  guard foo != nil else {
    return
  }
  
  foo!.prop = “new”
}

I propose the following option:

obj.methodWithCallback() {(foo, bar) in
  guard foo else {
    return
  }
  
  foo.prop = “new”
}

This reduces the seemingly redundant "guard let foo = foo” statement and removes the unnecessary forced optional unwrapping.

- Justin

2

Yes, this is the proper channel to discuss this kind of proposal.

What you’re proposing has been brought up before, or as Chris Lattner put it:
“Yes, this has thoroughly been beaten to death. It is also outside the scope of Swift 4 stage 1. That said, it is such a glaring problem that we’ll have to deal with it at some point.”
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028448.html

I don’t recall if there was a conclusion other than that it was out of scope.

This message from 26 October 2016 seems to be the start of the longest discussion of it that I could find:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/028440.html

Also, Erica Sadun drafted a proposal for it:

Unfortunately, given how close to release it is, I would guess that it’s still out of scope for Swift 4.
If it’s out of scope, Ted Kremenek very recently gave some input on “Swift phases and mis-timed proposals”:
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170612/037340.html

Regards,
David

···

On 10 Jun 2017, at 06:07, Justin Oroz via swift-evolution <swift-evolution@swift.org> wrote:

First time trying to contribute, hopefully this is the proper channel to submit.

I propose an addition to the guard let statement to allow for replacement of optionals with unwrapped values.

ex)

two current options

obj.methodWithCallback() {(foo, bar) in
  guard let foo = foo else {
    return
  }
  
  foo.prop = “new”
}

OR

obj.methodWithCallback() {(foo, bar) in
  guard foo != nil else {
    return
  }
  
  foo!.prop = “new”
}

I propose the following option:

obj.methodWithCallback() {(foo, bar) in
  guard foo else {
    return
  }
  
  foo.prop = “new”
}

This reduces the seemingly redundant "guard let foo = foo” statement and removes the unnecessary forced optional unwrapping.

- Justin

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

3

First time trying to contribute, hopefully this is the proper channel to submit.

I propose an addition to the guard let statement to allow for replacement of optionals with unwrapped values.

ex)

two current options

obj.methodWithCallback() {(foo, bar) in
  guard let foo = foo else {
    return
  }
  
  foo.prop = “new”
}
  OR

obj.methodWithCallback() {(foo, bar) in
  guard foo != nil else {
    return
  }
  
  foo!.prop = “new”
}

I propose the following option:

obj.methodWithCallback() {(foo, bar) in
  guard foo else {
    return
  }
  
  foo.prop = “new”
}

This reduces the seemingly redundant "guard let foo = foo” statement and removes the unnecessary forced optional unwrapping.

There was a discussion about similar subject in the list and was decided IIRC that shadowing is not a good practice so it doesn't worth a special syntactic sugar. (correct me if I'm missing something)

Personally, I believe shadowing already (and will be) used very often(usually because we already have a good name for variable, and it is hard to invent one more) and *good* syntactic sugar for it will make Swift code more clean. But I like the suggestion with 'let' keyword for such shadowing to make it clear that 'foo' is shadowed(re-declared) with its unwrapped version :

obj.methodWithCallback() {(someMeaningfulName, bar) in
    guard let someMeaningfulName else {
      return
    }
    
    someMeaningfulName.prop = “new”
}

Note that if it's 'foo' - it seems not a problem to write
guard let foo = foo else {..},
but when we have
guard let someMeaningfulName = someMeaningfulName else {..}
, we have to parse each variable to check if the same name declared or probably different name. Plus DRY principle.

if let someMeaningfulName {
   // unwrapped someMeaningfulName here
}

instead of

if let someMeaningfulName = someMeaningfulName {
}

···

On 10.06.2017 7:07, Justin Oroz via swift-evolution wrote:

- Justin

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