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

[Xiaodi Wu]

On Fri, Jun 16, 2017 at 14:42 Paul Cantrell <cantrell at pobox.com> wrote:

> On Jun 16, 2017, at 2:26 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> 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.
>
>
> I wouldn’t consider new warnings to be “breakage.” Warnings offer a
> gentler migration path than non-compilation.
>

> Unfortunately, the single keyword approach wouldn’t support warnings the
> same way.
>

No, but even that could offer benefits, and if transitional it would phase
in the benefits while phasing in the change.

So it’s really a question of what the tolerance for breakage is among the
> core team.
>

Indeed.


>
>
>> 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/6e6ebd3a/attachment.html>