I support the first part, removing `case let` in a switch. I actually prefer one let out front in many ways but I have a much stronger preference for eliminating a 'style' choice that dramatically impacts the interpretation of the code. Binding each value is more explicit, so I am fine with it winning.
The `if case` stuff… I don't really agree with as much. TJ On Mon, Mar 6, 2017 at 7:35 PM, Erica Sadun via swift-evolution < [email protected]> wrote: > Bug report filed with warning emitting request: > > https://bugs.swift.org/browse/SR-4174 > > -- E > > On Mar 1, 2017, at 1:58 PM, Pyry Jahkola <[email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 > > 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 valuesenum Value<T> { case > one(T), two(T, T), three(T, T, T) } > // An example with two associated valueslet example2: Value<Character> = > .two("a", "b") > // A bound symbollet 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -- > Pyry Jahkola > [email protected] > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
