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

Jonathan Hull jhull at gbis.com
Tue Mar 7 14:31:38 CST 2017


Would ‘if let foo = foo’ still be allowed?


> On Mar 7, 2017, at 12:14 PM, Erica Sadun via swift-evolution <swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170307/165b4146/attachment.html>


More information about the swift-evolution mailing list