I like this proposal a lot and also like Xiaodi’s suggestion that these be made into @ attributes.
> On Jun 14, 2017, at 1:48 PM, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > I like that this is minimal impact because it is optional. Since it is > optional, I wonder if making it visually distinct from the mandatory keywords > such as "override" for classes would be optimal, perhaps by making these > @annotations. > > Otherwise the naming is near perfect, IMO. It follows by analogy with > `override` and `convenience`. There is one nit here that `override func` > reads well in two senses: it's an overriding function with a certain > signature _and_ it's overriding a function with that signature. Moreover, > "override" can be read as a noun (a nouned verb, but plausibly a noun > nonetheless), fitting in better with "convenience" and "default." By > contrast, an `extend func` would be an extending function _but_ it's not > extending a function, so it may read more awkwardly. It's also definitely not > a noun. Might it be possible simply to reuse the keyword `extension` in this > context? > > As to the overall design, I like this much better than all previous > alternatives, which are amply discussed in your proposal text. > > >> On Wed, Jun 14, 2017 at 12:11 PM, 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 >> >> Thanks in advance for your thoughtful feedback, >> >> -- E >> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
