[swift-evolution] Proposal: Optional Binding Shorthand Syntax

Chris Lattner clattner at apple.com
Thu Dec 3 16:42:35 CST 2015


> On Dec 3, 2015, at 2:18 PM, Kevin Ballard <kevin at sb.org> wrote:
> 
> It's actually not doing the same thing, and what you're suggesting has
> no precedent.
...
> Furthermore, to anyone not
> already familiar with the proposed rule, `if let foo {` is meaningless;
> it does not tell the reader what it's actually doing, and its behavior
> cannot be inferred from any other language rule.

Right.

“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


> 
> -Kevin Ballard
> 
> On Thu, Dec 3, 2015, at 01:17 PM, Zef Houssney wrote:
>> Thanks for your thoughts David!
>> 
>> I would argue that it does support stated objectives of Swift, like "the
>> syntax is concise yet expressive.”
>> 
>> In the majority of cases having a lot of esoteric syntax is a problem.
>> However, with this being such a fundamental part of every day programming
>> in Swift, I find it to be a perfect place to reduce friction. I also find
>> it to be quite understandable and intuitive, unlike the three examples of
>> Swift 3 changes that you gave, which are more specialized and less
>> frequently encountered.
>> 
>> Also, I just noticed that this isn’t unprecedented and that a similar
>> idiom actually currently used in Swift to assign constants when pattern
>> matching inside a Switch:
>> 
>> case let (x, y):
>> 
>> That is doing fundamentally the same thing that I’m suggesting. It
>> assigns a constant without using `=`, because the value is already known.
>> 
>> Zef
>> 
>> 
>> 
>>> On Dec 3, 2015, at 1:26 PM, David Hart <david at hartbit.com> wrote:
>>> 
>>> I understand the reasoning of this proposal but it seems to go against the objectives the Swift team has been striving towards lately of:
>>> 
>>> - simplifying the language
>>> - making code more explicit by removed by shorthand syntax
>>> - removing redundant syntax for achieving the same behavior 
>>> 
>>> You can see examples of this in the latest changes to the language:
>>> 
>>> - removal of the # symbol in the first argument name as a shorthand to defining the argument name twice
>>> - removal of the ++ and -- prefix and postfix operators in Swift 3
>>> - removal of the var modifier in argument declaration and if/guard/while/for in blocks in Swift 3
>>> 
>>> I tend to agree with their philosophy to remove these shorthand syntaxes which make the language more difficult to learn (when all these features are taken as a whole) and potentially making the grammar more complicated only for the benefit of a shorthand syntax which also has the disadvantage of allowing two different syntaxes for the same semantics.
>>> 
>>> Just my 2 cents :)
>>> 
>>> 
>>> 
>>> Sent from my iPhone
>>>> On 03 Dec 2015, at 20:52, Zef Houssney <zefmail at gmail.com> wrote:
>>>> 
>>>> Hello. This is exciting!
>>>> 
>>>> I have an idea I’ve been mulling over for a while to reduce a common source of clutter in Swift code.
>>>> 
>>>> The idea is to introduce a new syntax for Optional Binding:
>>>> 
>>>> Instead of:
>>>> 
>>>> if let foo = foo { } 
>>>> 
>>>> You could simply use:
>>>> 
>>>> if let foo { } 
>>>> 
>>>> 
>>>> I’ve written up a draft of a proposal here with additional information and motivations:
>>>> https://github.com/zef/swift-evolution/blob/master/proposals/00xx-optional-binding-shorthand.md
>>>> 
>>>> 
>>>> What do you think?
>>>> 
>>>> Thank you!
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list