Re: [swift-evolution] [Discussion] Simplifying case syntax

Please respond to that email thread rather than this one. Thank you. -- E > On Mar 7, 2017, at 7:25 PM, David Waite wrote: > > I don’t fully understand - are you saying to comment on the gist as if it > were a discussion forum? > > -DW > >> On Mar 7, 2017, at 1:25 PM, Erica Sadun via swift-e

Re: [swift-evolution] [Discussion] Simplifying case syntax

I don’t fully understand - are you saying to comment on the gist as if it were a discussion forum? -DW > On Mar 7, 2017, at 1:25 PM, Erica Sadun via swift-evolution > wrote: > > I've put together everything I have about cases and unwrapping here: > > https://lists.swift.org/pipermail/swift-e

Re: [swift-evolution] [Discussion] Simplifying case syntax

I've put together everything I have about cases and unwrapping here: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033588.html So please move the discussion there. Thanks! -- E > On M

Re: [swift-evolution] [Discussion] Simplifying case syntax

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 winn

Re: [swift-evolution] [Discussion] Simplifying case syntax

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 wrote: > > I guess I should also include the example where the user actually wanted the > oldValue to be "x": > >

Re: [swift-evolution] [Discussion] Simplifying case syntax

Hi Erica, thanks for restarting the discussion—I hope that it will be considered on topic for stage 2. I agree that the part with preventing let .case(existingVar, newVar) should be moved out of the proposal, because these issues are orthogonal. So the options with ~= and := will differ only in th

Re: [swift-evolution] [Discussion] Simplifying case syntax

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-evol

Re: [swift-evolution] [Discussion] Simplifying case syntax

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: e

Re: [swift-evolution] [Discussion] Simplifying case syntax

> On Mar 1, 2017, at 2:17 PM, Erica Sadun wrote: > >> >> On Mar 1, 2017, at 11:46 AM, Matthew Johnson wrote: I agree that the ambiguity created by moving `let` outside the local = binding context is problematic. I alway place `let` immediately = alongside the binding for

Re: [swift-evolution] [Discussion] Simplifying case syntax

> On Mar 1, 2017, at 11:46 AM, Matthew Johnson wrote: >>> >>> I agree that the ambiguity created by moving `let` outside the local = >>> binding context is problematic. I alway place `let` immediately = >>> alongside the binding for this reason. =20 >>> >>> In design 2 do you disallow matching

Re: [swift-evolution] [Discussion] Simplifying case syntax

Sent from my iPad > On Feb 28, 2017, at 2:17 PM, Erica Sadun wrote: > > >> On Feb 28, 2017, at 12:19 PM, Matthew Johnson wrote: >> >> --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812 >> Content-Transfer-Encoding: quoted-printable >> Content-Type: text/plain; >>charset=utf-8 >> >> I a

Re: [swift-evolution] [Discussion] Simplifying case syntax

Would you agree with the following arguments? > On 1 Mar 2017, at 15:57, Xiaodi Wu wrote: > > The criteria for a source-breaking change in Swift 4 are as follows: > > - The existing syntax/API being changed must be actively harmful. The current pattern matching syntax is inconsistent which mak

Re: [swift-evolution] [Discussion] Simplifying case syntax

The criteria for a source-breaking change in Swift 4 are as follows: - The existing syntax/API being changed must be actively harmful. - The new syntax/API must clearly be better and not conflict with existing Swift syntax. - There must be a reasonably automatable migration path for existing code.

Re: [swift-evolution] [Discussion] Simplifying case syntax

I would think that removing confusion and simplifying + rationalising the syntax IS the definition of a breaking change justified :). I do not see how Erica's proposal is in any way contrary to the philosophy behind the language or is removing anything people really depend on now (in terms of ex

Re: [swift-evolution] [Discussion] Simplifying case syntax

Agree. Design 1 seems like an improvement over the status quo. Barring unexpected downsides to this, it's then a question of whether the improvements are large enough to justify a breaking change. On Tue, Feb 28, 2017 at 3:57 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote:

Re: [swift-evolution] [Discussion] Simplifying case syntax

I’m happy that someone is trying to fix this small wart in the language. I’ve always wanted something like Design 1. It makes sense because we are already used to the pattern matching operator and we finally fix the inconsistencies between if/guard and switch. > On 28 Feb 2017, at 20:01, Erica

Re: [swift-evolution] [Discussion] Simplifying case syntax

I suggest you split this into 2 separate proposals. The second part seems much, much more controversial than the first. Cheers, Jaden Geller > On Feb 28, 2017, at 11:01 AM, Erica Sadun via swift-evolution > wrote: > > The following draft proposal addresses one matter of substance (eliminating

Re: [swift-evolution] [Discussion] Simplifying case syntax

> On Feb 28, 2017, at 12:19 PM, Matthew Johnson wrote: > > --Apple-Mail=_99FCC835-0665-499E-84F7-EB04BAEF8812 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; > charset=utf-8 > > I agree that the ambiguity created by moving `let` outside the local = > binding cont

Re: [swift-evolution] [Discussion] Simplifying case syntax

I agree that the ambiguity created by moving `let` outside the local binding context is problematic. I alway place `let` immediately alongside the binding for this reason. In design 2 do you disallow matching a value using an existing name? If so, how do users match values bound to an exist

Re: [swift-evolution] [Discussion] Simplifying case syntax

I like the ~> operator, but not := operator. It makes the language inconsistent. Then we should allow using it without "if" just like this: mylet := "hey there" I think we should keep let as it was and avoid := P.S.: it also looks too much Pascal-ish :) On Tue, 28 Feb 2017 at 21:02 Erica Sadun v

[swift-evolution] [Discussion] Simplifying case syntax

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