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 
> <swift-evolution@swift.org> 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 
>> <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

Reply via email to