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

Erica Sadun erica at ericasadun.com
Tue Mar 7 17:30:51 CST 2017


> On Mar 7, 2017, at 3:44 PM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I like some of this, but as a single proposal, it does too many things at once.

I deliberately moved it out of proposal format for that reason, so it could be discussed first.

> - The `case let .some(foo)` vs. `case .some(let foo)` issue could be a targeted proposal.
> (I really like this)

I put it in as a bug report (link in repo) based on ?Anton's? suggestion but Jordan says this 
isn't similar to normal warnings they emit.

> - The Unwrappable protocol (and keyword) is interesting; it can probably be its own discussion.
> (feels unnecessary, without feeling wrong)

Unwrappable is driven from Chris L to simplify language implementation and support
the eventual introduction of Result/Either. If that's not needed anymore, I'm sure 
he or others will let me know and I'll cross out. I love the idea of an easy way
to use existing syntax sugar for custom types.

> - I’m not clear about the proposed solution about shadowing. Is it’s simply the `let` restriction or is there more to it? In any case I don’t think the compiler should disallow shadowing, even if there is a new warning; if there is a new warning there must be a way to spell a shadowed name so as to silence the warning.

Several points touch on shadowing:

* creating something more readable and safe with `unwrap`
* removing a danger that cannot be addressed with `unwrap` for multi-associated values

> - The whole pattern-binding in if/guard/for statements is certainly ripe for improvement; I agree with Anton Zhilin’s comment that pattern-before-expression is confusing. The switch statement puts the expression before the patterns, and it reads well. More than once, after having written an `if case` statement, I later changed it to a `switch` statement in order to improve readability.

I have no problem switching them and doing =~ vs ~= but I remember this point being
brought up and there was a clear design decision to do pattern first value second. I'll 
defer that to anyone who knows the background.

-- E

> 
> Cheers,
> Guillaume Lessard
> 



More information about the swift-evolution mailing list