[swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs

Xiaodi Wu xiaodi.wu at gmail.com
Wed Jun 14 12:48:51 CDT 2017


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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170614/48e36505/attachment.html>


More information about the swift-evolution mailing list