[swift-evolution] [Pitch] Introducing role keywords to reduce hard-to-find bugs
panajev at gmail.com
Thu Jun 15 00:14:04 CDT 2017
Sent from my iPhone
> On 15 Jun 2017, at 05:41, Paul Cantrell via swift-evolution <swift-evolution at swift.org> wrote:
>>> On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>>> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
>>> On 14.06.2017 21:23, Haravikk via swift-evolution wrote:
>>>>> On 14 Jun 2017, at 19:08, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution <swift-evolution at swift.org <mailto: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.
>>>> Hmm, I'm inclined to agree with David that only the default keyword really seems like it's necessary, and that extend can be implied.
>> I think a good plan would be to make default required in a later Swift version (Swift 5) for example, and only warn for now.
> I like only having “default,” and I like David’s plan for achieving that.
> • • •
> It seems that this proposal could help mitigate the problems described in the classic “Ghost of Swift Bugs Future” (https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future). There’s a nice new convention (I think?) of:
> `extend` / no modifier in extension → static dispatch
> `default` in extension → dynamic dispatch
> (Does this always hold in an extensions?)
> Knowing whether the extension’s author •intended• static or dynamic dispatch could also allow the compiler to give better warnings: about shadowing at declaration sites, and also also potentially at call sites where multiple extension methods could match depending on the compile-time type of the receiver.
To me static dispatch is an optimisation over dynamic one, but it should only be applied when it cannot introduce side effects or when the programmer is asking for it explicitly: code path execution should never change no matter how we are casting a reference (base type or subclass) and users should know if they are implementing a method that will never be called as it shadows a default method only declared in a protocol extension.
Thanks for reminding the list of this article: https://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future
These problems should be addressed.
> Might it be worth describing some of these warnings out in the proposal? I realize warnings don’t require full swift-evo treatment, but it would be nice to at least sketch out in the “Impact on Existing Code” section what the warnings might look like.
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution