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

[Vladimir.S]

On 15.06.2017 0:51, David Hart wrote:
> 
>> On 14 Jun 2017, at 22:37, Vladimir.S via swift-evolution <swift-evolution at swift.org 
>> <mailto: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> 
>>>> <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> 
>>>> <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'm not so sure. If they are optional, then it depends on developer if he/she wants 
>> to explicitly mark some func to avoid possible errors. Please look here :
>>
>> 1. First we have this
>>
>> protocol A {
>>  func foo() {}
>> }
>>
>> and we  write extension (possible in another file)
>>
>> extension A {
>>  extent func bar() {} // I'm sure currently I want *additional* 'bar' method
>> }
>>
>> 2. Then 'A' protocol has been changed for some reason :
>>
>> protocol A {
>>  func foo() {}
>>  func bar() {}
>> }
>>
>> Now, if we have 'extent' - we(compiler) can detect the problem here('bar' was not 
>> the default implementation for A's requirement). Without 'extent' - 'bar' will be 
>> default implementation without our intent for this.
>>
>> So, in case suggested keywords are both optional - IMO we need both.
>> In case 'default' is required - then yes, we need only it.
> 
> 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. If I remember correctly, the Core Team has 
> redefined source-stability as the ability for the compiler to continue to compile a 
> previous version of Swift without new errors, but gives us a little bit of wiggle 
> room to introduce some new errors in new versions of Swift (see Swift 4 for example).
> 
> I see two ways:
> 
>   * Either we acknowledge that this proposal is important for the future of Swift and
>     we are ready to impose a future version of Swift making default required,
>   * Or if its not, we need to keep both keywords and they need to stay optional. In
>     that case, I would personally reconsider the usefulness of the proposal: it would
>     introduce a feature that is not easily discoverable, introduces a new keyword,
>     and is more complex than it ought to be.
> 
> 
> Of course, my opinion is that it’s definitely worth the breakage in a future version 
> of Swift.


For me it's worth the breakage even in current version of Swift ;-) So, yes, support 
the required 'default' in future version of Swift.

> 
> David.
> 
>>
>>> My preference would be to just add the default keyword, and have breaches treated 
>>> as warnings using the current behaviour, which we can eliminate and elevate to an 
>>> error in future once people have had a chance to change their code.
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>