[swift-evolution] [Pitch] Introducing `Unwrappable` protocol
erica at ericasadun.com
Tue Mar 7 14:14:12 CST 2017
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
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.
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution