Sent from my iPhone

> On 15 Jun 2017, at 05:41, Paul Cantrell via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> 
>>> On Jun 14, 2017, at 4:51 PM, David Hart via swift-evolution 
>>> <swift-evolution@swift.org> wrote:
>>> 
>>> 
>>> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution 
>>> <swift-evolution@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@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>>> 
>>>>> On Wed, Jun 14, 2017 at 1:01 PM, David Hart via swift-evolution 
>>>>> <swift-evolution@swift.org <mailto:swift-evolution@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.

+10000

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.
> 
> Cheers,
> 
> Paul
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to