It’s worth mentioning that the normal let binding can be used for pattern
matching:
let (a, b, c) = foo()
This nicely parallels the existing case syntax:
if case let .blah(a, b, c) = bar() { … }
It would feel inconsistent if the order switched when in a conditional binding.
I would prefer that `case` was removed to best mirror the normal syntax,
requiring `?` or `.some` to be used for optionals
if let .blah(a, b, c) = bar() { … }
if let unwrapped? = wrapped { … }
if let .some(unwrapped) = wrapped { … }
but I realize this is source-breaking, so I’m happy with the existing syntax.
Unrelated: I feel like a single case [closed] enum shouldn’t require an `if` to
match, similar to tuples:
let .onlyCase(a) = baz()
I’m not sure this is particularly useful, but it seems consistent; if a pattern
is irrefutable, a conditional binding is unnecessary.
Anyway, I’m definitely -1 on the idea as a whole. It doesn’t clearly seem
cleaner to me, and it is majorly source breaking. I’m +1 for a warning to avoid
accidental shadowing—why doesn’t it give an unused variable warning already?
Seems odd…
> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> I have been involved in several separate related draft proposals for
> discussions
> that were cut off about 4 months ago. I believe they meet the criteria for
> Stage 2,
> but I'm doing a poor job presenting them coherently on-list.
>
> Because of that, I'm going to start over here, hopefully pulling in all the
> details
> and allowing the community to provide feedback and direction. The following
> gist is an amalgam of work I was discussing with Xiaodi Wu, Chris Lattner, and
> David Goodine.
>
> https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f
> <https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f>
>
> I've decided to link to the gist rather than paste the entire proposal as
> that never seems to
> really work here.
>
>
> In a nutshell:
>
> Unwrapping values is one of the most common Swift tasks and it is
> unnecessarily complex.
>
> Consider the following solutions:
>
> Introduce an unwrap keyword for Optional values
> Introduce an Unwrappable protocol for associated-value enumerations.
> Apply unwrap to non-Optional values.
> Extend for and switch.
> Fix pattern match binding issues.
> Simplify complex binding.
>
> <https://gist.github.com/erica/aea6a1c55e9e92f843f92e2b16879b0f#motivation>Motivation
>
> Unwrapping with conditional binding and pattern matching is unnecessarily
> complex and dangerous:
>
> Using "foo = foo" fails DRY principles
> <https://en.wikipedia.org/wiki/Don%27t_repeat_yourself>.
> Using case let .some(foo) = foo or case .some(let foo) = foo fails KISS
> principles <https://en.wikipedia.org/wiki/KISS_principle>.
> Using the = operator fails the Principle of Least Astonishment
> <https://en.wikipedia.org/wiki/Principle_of_least_astonishment>.
> Allowing user-provided names may shadow existing variables without compiler
> warnings.
> The complexity and freedom of let and var placement can introduce bugs in
> edge cases.
> -- E
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
