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

[Xiaodi Wu]

Sure, it’s not out of the question, technically. The question is whether a
migration of such scale is desirable, which is a difficult judgment call.
On Wed, Jun 14, 2017 at 16:43 David Hart <david at hartbit.com> wrote:

> On 14 Jun 2017, at 20:19, Matthew Johnson <matthew at anandabits.com> wrote:
>
>
> On Jun 14, 2017, at 1:12 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> On Wed, Jun 14, 2017 at 1:08 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
>> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> Sorry, initially sent off-list:
>>>
>>> I think this proposal is a great idea. But I would vote for the
>>> alternative of only having default and implicitly deducing extend when
>>> default is not specified:
>>>
>>
>> This wouldn't work with the fundamental design decision that these are
>> optional keywords, which IMO is absolutely key.
>>
>
> ...I may need to take this back; the design has annotations on the default
> and not on the overriding functions, which means there should be no
> negative impact on retroactive conformance (unless I'm mistaken). In that
> case, it might not need to be optional, and then reducing two keywords to
> one might be a nice idea…
>
>
> Making them optional is critical for source stability.  I think David’s
> suggestion is a better overall design but I’m not sure it will fly.  It
> would require a migrator to add `default` to all default implementations in
> protocol extensions in existing code.  The window for changes like that may
> have already passed.
>
>
> The Swift 4 compiler in -swift-version 3 modes generates extra warnings:
> as long as it compiles, it is still source-compatible.
>
>
> it would mimic how override works with only one keyword, it would not
>>> introduce a completely new keyword, and it would provide progressive
>>> disclosure (your usually start implementing types before going deeper in
>>> default implementations). Yes, it would generate warnings at all current
>>> default implementations, but it wouldn’t break source compatibility and
>>> would provide a lot of value for developers.
>>>
>>> Perhaps a future version of Swift could transform that warning into an
>>> error to provide the most value and really mirror the override behavior.
>>>
>>> On 14 Jun 2017, at 19:11, 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
>>>
>>>
>>> _______________________________________________
>>> 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/20170614/ba46712a/attachment.html>