[swift-evolution] Proposal: Optional Binding Shorthand Syntax

Kevin Ballard kevin at sb.org
Fri Dec 4 01:07:29 CST 2015 

If we change anything based on this, I’d suggest the simpler change of removing `if let`/`while let` and renaming `if case`/`while case` to `if let`/`while let`. Since Swift now has the ? pattern type to mean optional binding, it means that all existing instances of 

    if let foo = bar {

become the almost-identical

    if let foo? = bar {

That said, I’m not convinced we actually have to change anything, but if we do change anything, this seems like the change to make. Of course, it doesn’t actually solve the original poster’s problem of wanting to type less when shadowing an optional value, but I agree completely with Chris Lattner that the goal of Swift is not to be terse but to be readable.

-Kevin Ballard

> On Dec 3, 2015, at 9:15 PM, Sean Heber <sean at fifthace.com> wrote:
> 
> I am obviously biased in favor of a new keyword/construct for this. :) The more I think about it, the more convinced I am that the intent of these scenarios should be conveyed in the code clearly so it is easily seen by future maintainers of that code. It may also help to guide the design of code in the same way that guard seems to alter how I now think about writing a function.
> 
> In any event, it is clear that there is a strong desire to solve a pain point, assuming we have correctly identified what pain, exactly, we are trying to solve. :)
> 
> l8r
> Sean
> 
> 
> On Dec 3, 2015, at 10:57 PM, Zef Houssney <zefmail at gmail.com <mailto:zefmail at gmail.com>> wrote:
> 
>> Interesting thoughts! And thanks for the consideration Chris. Just a couple more thoughts and I’ll drop this :)
>> 
>> Chris, I love the way you put this:
>> 
>>> Since code is read more often than it is written, the real goal behind Swift is to let you write “more readable code” by eliminating boilerplate and other noise.
>> 
>> In my view, this proposal is aligned with that goal and it’s as much about readability as anything. I find this first example so much more readable at a glance, and I consider the duplicate names and equals sign to be in the boilerplate/noise category:
>> 
>> if let thing, otherThing, moreThings where thing > 0 { }
>> if let thing = thing, otherThing = otherThing, moreThings = moreThings where thing > 0 { }
>> 
>> 
>> Kevin, in regard to this:
>> 
>>> Furthermore, to anyone not already familiar with the proposed rule, `if let foo {` is meaningless
>> 
>> 
>> I agree with David in that the existing syntax is already at the point where your statement is also true. There is nothing in the current syntax that indicates that you are unwrapping the optional. It’s only through learning or familiarity with other languages that one understands it. The = indicates assignment, but the unwrapping is learned and specific to that context. The jump to this seems super easy to grok.
>> 
>> Also my point isn’t that it’s doing the same thing technically, but that it’s a similar concept — assigning to a constant with the value derived implicitly by the context instead of directly through ‘=‘.
>> 
>> The idea of another keyword like “when” also seems plausible to me, though it’s a much more drastic change.
>> 
>> 
>> 
>> 
>>> On Dec 3, 2015, at 8:13 PM, Sean Heber <sean at fifthace.com <mailto:sean at fifthace.com>> wrote:
>>> 
>>> What about lifting the whole concept out of "if" or "guard" and making a new construct that directly communicates the intent?
>>> 
>>> For example:
>>> 
>>> when foo { ... }
>>> 
>>> Which could be combined with "where" to generate an if-like construct:
>>> 
>>> when foo where foo.isSomething { ... }
>>> 
>>> Inside the code block, you can access foo directly and it isn't shadowed - so if it was a var, it is mutable, etc.
>>> 
>>> l8r
>>> Sean
>>> 
>>> 
>>> On Dec 3, 2015, at 8:25 PM, David Waite <david at alkaline-solutions.com <mailto:david at alkaline-solutions.com>> wrote:
>>> 
>>>> I might argue that if let is already an odd case; people often read it equivalent to "if (let x=x)”, but “let x=x” has completely different behavior outside the context of an if let statement (I in fact had to try it before I realized it does, in fact, work). Obviously, 'let x=x’ on its own could not have the same behavior.
>>>> 
>>>> In that spirit, I propose an alternative feature:
>>>> 
>>>> if foo? { … }
>>>> 
>>>> where the variable is not shadowed by a copy - instead, inside the block it behaves as an implicit unwrapped optional, including keeping any mutability.
>>>> 
>>>> so for example:
>>>> 
>>>>  func foo(x:Int?) { 
>>>>      if var x = x { // var so it can be assigned
>>>>          x++ 
>>>>      } 
>>>>      print(x) 
>>>>  } 
>>>> 
>>>> foo(1) // => 1, updating the aliased x does not do anything
>>>> 
>>>> # working code in Swift 1.2
>>>>  func bar(x:Int?) { 
>>>>      var y=x 
>>>>      if let x=x { 
>>>>          y=x+1 
>>>>      } 
>>>>      print(y) 
>>>>  } 
>>>> bar(1) # => Optional(2)
>>>> 
>>>> # proposed
>>>> func proposed(x:Int?) {
>>>>      var y = x // since swift 3 won't have var function arguments
>>>>      if y? { // var so it can be assigned
>>>>          y++ 
>>>>      } 
>>>>      print(y) 
>>>>  } 
>>>> 
>>>> proposed(1) // => Optional(2)
>>>> 
>>>> -DW
>>>> 
>>>>> On Dec 3, 2015, at 3:42 PM, Chris Lattner <clattner at apple.com <mailto:clattner at apple.com>> wrote:
>>>>> 
>>>>> 
>>>>> “if let foo {“ is a frequently proposed extension to the syntax, but it is not one that we’re likely to ever add.
>>>>> 
>>>>> I agree that this is a common pattern, and it would allow you to “write less code”, but that isn’t the goal of Swift.  Since code is read more often than it is written, the real goal behind Swift is to let you write “more readable code” by eliminating boilerplate and other noise. 
>>>>> 
>>>>> Reducing syntax isn’t itself a goal, particularly if the result could/would be confusing for someone who has to read and maintain your code later.
>>>>> 
>>>>> -Chris
>>>> 
>>>> _______________________________________________
>>>> 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 <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/20151203/545fb1d3/attachment-0001.html>

More information about the swift-evolution mailing list