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

Charlie Monroe charlie at charliemonroe.net
Tue Mar 7 23:28:44 CST 2017


> On Mar 8, 2017, at 2:33 AM, Guillaume Lessard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Mar 7, 2017, at 4:30 PM, Erica Sadun <erica at ericasadun.com> wrote:
>> 
>> I deliberately moved it out of proposal format for that reason, so it could be discussed first.
> 
> I see now.
> 
> 
>>> - 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 like it too, but I’m not sure how useful it would really be.

Very much for API calls where the callback either has an enum or a callback that has two optionals - return value and an error.

I am definitely +1 on this proposal.

> 
> Thanks for the clarification!
> Guillaume
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution



More information about the swift-evolution mailing list