[swift-evolution] [Pitch] Introducing `Unwrappable` protocol
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!
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution