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

[Xiaodi Wu]

On Fri, Jun 16, 2017 at 14:06 Paul Cantrell via swift-evolution <
swift-evolution at swift.org> wrote:

> On Jun 16, 2017, at 1:14 PM, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Jun 16, 2017, at 8:44 AM, David Hart <davidhart at fastmail.com> wrote:
>
> Okay, I undertand. I’m just worried that the proposal is a net negative if
> the keywords stay optional. I’ll mention it in more detail once we get to
> the review period.
>
> Thanks for the work on the proposal!!
>
>
> I believe a breaking change has little chance of being accepted at this
> point in the language lifecycle. Adding opt-in compiler auditing to
> increase safety is, IMO, a net positive. It's a deliberate trade-off. We
> have included other designs to allow the core team to choose an alternative
> they feel is best for the philosophy and direction of Swift. This doesn't
> close the door to future language releases enhancing the concept, phasing
> out the second keyword, or introducing keywords for additional safety
> auditing.
>
> I find it a dangerous philosophy to insist that any new proposal be
> ideologically pure. Imperfect proposals can still improve the language
> within the realities of the timelines, user base, and code base of the
> Swift community.
>
>
> -- E
>
>
> I share David’s concern. I also tend to think Erica’s correct about
> breaking changes. If the core team says “go ahead and break it,” then I’m
> all for it, but that seems unlikely.
>
> FWIW, if we’re sticking with the two-keyword approach, the language could
> emit warnings for _any_ extension members that aren’t marked with either
> `extend` or `default`.
>

If the language were to do that, then it would certainly be superior to use
the one-keyword approach, since this is equal breakage with an extra
keyword.


> P
>
>
>
>
> On 16 Jun 2017, at 16:33, Erica Sadun <erica at ericasadun.com> wrote:
>
> As we say in our introduction, we're pitching the most conservative
> approach.
>
> The proposal was designed for minimal language impact. It chooses a
> conservative approach that can be phased in first over time and language
> release over more succinct alternatives that would impact existing code
> bases.
>
>
> We discuss the one keyword version (which most of us are a fan of) in the
> alternatives. The core team has to decide how much they're willing to allow
> existing code to warn and/or break, which is the consequence of the one
> keyword solution.
>
> -- E
>
> On Jun 16, 2017, at 7:44 AM, David Hart <davidhart at fastmail.com> wrote:
>
> Erica, any thoughts on only having default and making it an error in a
> future version of Swift like was discussed on this thread? The idea seems
> to have a few supporters.
>
> On 16 Jun 2017, at 15:33, Erica Sadun via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jun 14, 2017, at 11:46 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> on Wed Jun 14 2017, Chris Lattner <swift-evolution at swift.org> wrote:
>
> On Jun 14, 2017, at 10:11 AM, 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
> <https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4>
>
> Thanks in advance for your thoughtful feedback,
>
>
> +1 on the idea of this.
>
>
> ditto.  IMO it also makes the protocol extension much more expressive
> and easy to read.
>
> --
> -Dave
>
>
>
> Pull request: https://github.com/apple/swift-evolution/pull/724
>
> -- E
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> 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/20170616/457ec030/attachment.html>