[swift-evolution] Proposal: Optional Binding Shorthand Syntax

[Kevin Ballard]

It's actually not doing the same thing, and what you're suggesting has
no precedent. `case let (x, y)` is completely unrelated; it does not
look up existing bindings for the identifiers `x` and `y`, but instead
is matching against a previously-specified value. But in your proposed
`if let foo {`, you do not specify the value anywhere, and instead rely
on the assumption that you're trying to match against an existing value
with the same identifier. But nowhere else in the language does it ever
assume that any identifier has any relation to another identifier that
it shadows. And nowhere else in the language does it make an assumption
about what data you want to operate over. 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.

-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