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 <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170306/033588.html>
So please move the discussion there. Thanks! -- E > On Mar 6, 2017, at 8:47 PM, T.J. Usiyan <[email protected]> wrote: > > 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. I've broken it down to its own problem/solution > > The `if case` stuff… I don't really agree with as much. I grant it's one of the things that would have gone down much better way earlier in Swift's development timeline, but that kept getting pushed forward again and again. > > TJ > > On Mon, Mar 6, 2017 at 7:35 PM, Erica Sadun via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > 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 <[email protected] >> <mailto:[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 > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
