> 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 > <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. > > 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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
