Sure, it’s not out of the question, technically. The question is whether a migration of such scale is desirable, which is a difficult judgment call. On Wed, Jun 14, 2017 at 16:43 David Hart <da...@hartbit.com> wrote:
> 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> wrote: > > On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution < >> 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> 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 >>> >>> Thanks in advance for your thoughtful feedback, >>> >>> -- E >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> 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 >>> >>> >> > _______________________________________________ > swift-evolution mailing list > 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
