I too really like this proposal; personally I can attest to how it probably would have saved some time and headache with the Foundation overlay as well as swift-corelibs-foundation (specifically when adopting Collection and friends for types)
Would it be reasonable to have this apply to typealiases as well? Or does not only make sense for functions/properties etc? I presume this would also be something exposed in the interfaces when viewing APIs? Does this perhaps have any objc protocol interaction? (e.g. do we need an attribute to adopt things? Or perhaps can we leverage this to address the disparity 'tween objc protocols and swift protocols for optional methods via this same mechanism?) > On Jun 14, 2017, at 10:46 PM, Dave Abrahams via swift-evolution > <[email protected]> wrote: > > > on Wed Jun 14 2017, Chris Lattner <[email protected] > <mailto:[email protected]>> wrote: > >>> On Jun 14, 2017, at 10:11 AM, Erica Sadun via swift-evolution >>> <[email protected]> wrote: >>> >>> Some pals and I have been kicking an idea around about introducing >>> better ways to support the compiler in protocol extensions. We want >> >>> to eliminate some hard-to-detect bugs. We've been brainstorming on >>> how to do this without affecting backward compatibility and >>> introducing a minimal impact on keywords. >>> >>> We'd love to know what you think of our idea, which is to introduce >>> "role" keywords. Roles allow the compiler to automatically check the >>> intended use of a extension member definition against its protocol >>> declarations, and emit errors, warnings, and fixits as needed. We >>> think it's a pretty straightforward approach that, if adopted, >>> eliminates an entire category of bugs. >>> >>> The draft proposal is here: >>> https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4 >>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4 >>> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>> >>> >>> Thanks in advance for your thoughtful feedback, >> >> +1 on the idea of this. > > ditto. IMO it also makes the protocol extension much more expressive > and easy to read. > > -- > -Dave > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
