[swift-evolution] Ownership on protocol property requirements

[Greg Spiers]

I've opened a pull request for the draft proposal. As others have said
it would be good to get this inconsistency fixed in time for Swift 4.
I'd be up for discussion around actually giving these keywords meaning
at some point, but there's lots of questions around that.

Thanks everyone for the feedback and help :)

https://github.com/apple/swift-evolution/pull/707

On Mon, May 8, 2017 at 11:20 PM, David Hart <david at hartbit.com> wrote:
> LGTM! I'd go ahead with opening a PR. Time is running out!
>
>> On 8 May 2017, at 14:40, Greg Spiers <gspiers at gmail.com> wrote:
>>
>>> On Mon, May 8, 2017 at 7:57 AM, David Hart <david at hartbit.com> wrote:
>>> Sounds great! It should be an easy one to get through,
>>
>> Thanks David, appreciate it :) I've created a draft of the proposal.
>> Any feedback would be very welcome. I wasn't sure if there was an
>> effect on ABI stability or API resilience. I don't think there would
>> be as this is only correcting syntax.
>>
>> Also, just adding the link again where I had a try at implementing the
>> warning/error. Hopefully that can be helpful in getting feedback about
>> the proposal as well.
>> https://github.com/gspiers/swift/commit/ecde3ec5f61f259f8a396618e9973bac04536fd0
>>
>>
>> # Remove ownership keyword support in protocols
>>
>> * Proposal: [SE-NNNN](NNNN-remove-ownership-keyword-support-in-protocols.md)
>> * Authors: [Greg Spiers](https://github.com/gspiers)
>> * Review Manager: TBD
>> * Status:
>> * Bug: [SR-479](https://bugs.swift.org/browse/SR-479)
>>
>> ## Introduction
>>
>> This proposal removes support for the keywords `weak` and `unowned`
>> for property declarations in a protocol.
>>
>> Swift-evolution thread: [Ownership on protocol property
>> requirements](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036495.html)
>> thread. (TODO: Add link to rest of discussion)
>>
>> ## Motivation
>>
>> Currently it's possible to use the weak/unowned keywords for a
>> property requirement in a protocol. This can lead to confusion as
>> specifying one of these keywords does not enforce or raise any
>> warnings in the adopting type of that protocol:
>>
>> ```swift
>>
>> class A {}
>>
>> protocol P {
>>    weak var weakVar: A? { get set }
>> }
>>
>> class B: P {
>>    var weakVar: A? // Not declared weak, no compiler warning/error
>> }
>>
>> ```
>>
>> This can lead to unexpected and surprising behaviour from the point of
>> view of users. They keywords themselves are currently meaningless
>> inside of a protocol but look like they would have an effect when the
>> protocol is adopted.
>>
>> ## Proposed solution
>>
>> Although the case could be made that the keywords should have meaning
>> in a protocol, as they are currently implemented today they don't have
>> an effect. This proposal aims to cleanup the misleading syntax and
>> isn't meant to remove functionality only correct to existing
>> behaviour.
>>
>> This proposal suggests removing support for `weak` and `unowned` in a protocol.
>>
>> ## Detailed design
>>
>> The compiler will flag the use of `weak` and `unowned` in a protocol
>> and suggest a fix to remove the keyword.
>>
>> ## Source compatibility
>>
>> This is a source breaking change but one that would only correct code
>> that is already has broken assumptions. For existing use the compiler
>> will raise a compilation error. When running in Swift 3 mode a warning
>> can be generated instead of an error. It could be possible to address
>> source compatibility through source migration as well.
>>
>> ## Effect on ABI stability
>>
>> This proposal does not affect ABI stability.
>>
>> ## Effect on API resilience
>>
>> This proposal should not effect API resilience.
>>
>> ## Alternatives considered
>>
>> There is an argument in making `weak` and `unowned` have meaning in a
>> protocol but this does open up other questions and is probably better
>> as a topic of a separate discussion/proposal. As this would be
>> additive it can be addressed at a later point when we have a clearer
>> understanding.
>