[swift-evolution] [Pitch] Introducing `Unwrappable` protocol

[Erica Sadun]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170307/4daaecac/attachment.html>