[swift-evolution] [Discussion] Simplifying case syntax

[Erica Sadun]

Bug report filed with warning emitting request: 

https://bugs.swift.org/browse/SR-4174 <https://bugs.swift.org/browse/SR-4174>

-- E

> On Mar 1, 2017, at 1:58 PM, Pyry Jahkola <pyry.jahkola at iki.fi> wrote:
> 
> I guess I should also include the example where the user actually wanted the oldValue to be "x":
> 
>     if case let .two(newValue, value) = example, value == oldValue { ... }
> 
> No surprises there, even if another conditional is required.
> 
> — Pyry
> 
>> On 1 Mar 2017, at 22.53, Pyry Jahkola via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Erica,
>> 
>> Instead of going into all these lengths introducing new syntax, why not simply turn it into a warning when a `case let` binding shadows an existing variable with the exact same type (which supposedly also conforms to Equatable)?
>> 
>> Examples, including how to silence the said warning:
>> 
>>     enum Value<T> { case one(T), two(T, T), three(T, T, T) }
>>     
>>     let example: Value<String> = .two("a", "b")
>>     let oldValue = "x"
>>     // (Besides, you probably intended `oldValue` to be a `Character` in your
>>     // example. Well, it's a `String` in mine.)
>>     
>>     if case let .two(newValue, oldValue) = example { ... }
>>     //                         ~~~~~~~~
>>     // warning: 'oldValue' shadows an existing variable of same type 'String'
>>     
>>     if case let .two(newValue, (oldValue)) = example { assert(oldValue == "b") }
>>     // Ok, adding extra parentheses silences the warning.
>> 
>>     if case let .one(example) = example { ... }
>>     // Ok, because there's no way the author would equate the `example: String`
>>     // in the LHS to the `example: Value<String>` of the RHS.
>>     
>>     let maybe: Optional = "perhaps"
>>     if case let maybe? = maybe { ... }
>>     if case let .some(maybe) = maybe { ... }
>>     // Again, none of these examples would be affected by the warning, because
>>     // the `maybe: String` bound in the `case let` has a different type than
>>     // the `maybe: String?` in the outer scope.
>> 
>> Personally, I do like the convenience that I can bind several variables with one `let` keyword in a case expression. And I can't see the appeal to making `~=`, let alone a completely new special-syntax assignment operator, more prominent in Swift.
>> 
>> — Pyry
>> 
>>> On 28 Feb 2017, at 21.01, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> The following draft proposal addresses one matter of substance (eliminating edge case errors by adopting at-site conditional binding) and one of style (using the pattern match operator consistently). Its discussion was deferred from Phase 1 and remains in a fairly early stage. Your feedback will help me decide whether this is a proposal I want to keep developing or one that I should set aside and focus on other matters. Thank you. -- E
>>> 
>>> The work-in-progress gist is here:  https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c <https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c> 
>>> 
>>> Simplifying case syntax
>>> 
>>> Proposal: TBD
>>> Author: Erica Sadun <https://github.com/erica>
>>> Status: TBD
>>> Review manager: TBD
>>>  <https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c#introduction>Introduction
>>> 
>>> This proposal re-architects case syntax grammar to reduce potential errors and simplify unwrapping enumerations. 
>>> 
>>> Swift-evolution thread: [Pitch] Reimagining guard case/if case <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20161024/tbd.html>
>>>  <https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c#motivation>Motivation
>>> 
>>> In its current design, Swift case binding suffers from two weaknesses.
>>> 
>>> Mixed external and internal let/var binding may introduce errors from uncommon edge cases.
>>> Real-world users may not consider the parallel construction between if case/guard case with switchstatements or naturally connect the two layouts.
>>>  <https://gist.github.com/erica/06dad9bbe1a70290fe6b89a64f73bc0c#internal-case-binding>Internal Case Binding
>>> 
>>> When pattern matching, it's common to bind a variable or constant. It's uncommon but legal to use a bound value as an argument. Adopting an "always explicit, always within the parentheses" rule adds consistency and safety to Swift. 
>>> 
>>> Consider the following enumeration and values:
>>> 
>>> // An enum with one, two, or three associated values
>>> enum Value<T> { case one(T), two(T, T), three(T, T, T) }
>>> 
>>> // An example with two associated values
>>> let example2: Value<Character> = .two("a", "b")
>>> 
>>> // A bound symbol
>>> let oldValue = "x"
>>> This code's goal is to conditionally bind newValue and pattern match the value stored in the oldValue symbol. The first example succeeds. The second example compiles and runs but does not match the coder's intent. Using an external letcreates a new oldValue shadow instead of pattern matching oldValue's stored value.
>>> 
>>> // Safe
>>> if case .two(let newValue, oldValue) = example2 { 
>>>     ... 
>>> }
>>> 
>>> // Syntactically legal but incorrect
>>> if case let .two(newValue, oldValue) = example2 { 
>>>     ... 
>>> }
>> (…)
>> 
>> _______________________________________________
>> 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>
> -- 
> Pyry Jahkola
> pyry.jahkola at iki.fi <mailto:pyry.jahkola at iki.fi>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170306/1e99e231/attachment.html>