> On 14 Jun 2017, at 20:19, Matthew Johnson <matt...@anandabits.com> wrote: > > >> On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Sorry, initially sent off-list: >> >> I think this proposal is a great idea. But I would vote for the alternative >> of only having default and implicitly deducing extend when default is not >> specified: >> >> This wouldn't work with the fundamental design decision that these are >> optional keywords, which IMO is absolutely key. >> >> ...I may need to take this back; the design has annotations on the default >> and not on the overriding functions, which means there should be no negative >> impact on retroactive conformance (unless I'm mistaken). In that case, it >> might not need to be optional, and then reducing two keywords to one might >> be a nice idea… > > Making them optional is critical for source stability. I think David’s > suggestion is a better overall design but I’m not sure it will fly. It would > require a migrator to add `default` to all default implementations in > protocol extensions in existing code. The window for changes like that may > have already passed.
The Swift 4 compiler in -swift-version 3 modes generates extra warnings: as long as it compiles, it is still source-compatible. >> >> it would mimic how override works with only one keyword, it would not >> introduce a completely new keyword, and it would provide progressive >> disclosure (your usually start implementing types before going deeper in >> default implementations). Yes, it would generate warnings at all current >> default implementations, but it wouldn’t break source compatibility and >> would provide a lot of value for developers. >> >> Perhaps a future version of Swift could transform that warning into an error >> to provide the most value and really mirror the override behavior. >> >> On 14 Jun 2017, at 19:11, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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> >>> >>> Thanks in advance for your thoughtful feedback, >>> >>> -- E >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
