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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
