Skip to content

Commit 2e0a04d

Browse files
committed
Add draft proposal for ownership keyword removal in protocols.
1 parent 55791d3 commit 2e0a04d

File tree

1 file changed

+62
-0
lines changed

1 file changed

+62
-0
lines changed
Lines changed: 62 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,62 @@
1+
# Remove ownership keyword support in protocols
2+
3+
* Proposal: [SE-NNNN](NNNN-remove-ownership-keyword-support-in-protocols.md)
4+
* Authors: [Greg Spiers](https://github.com/gspiers)
5+
* Review Manager: TBD
6+
* Status:
7+
* Pull Request: [apple/swift#11744](https://github.com/apple/swift/pull/11744)
8+
* Bug: [SR-479](https://bugs.swift.org/browse/SR-479)
9+
10+
## Introduction
11+
12+
This proposal removes support for the keywords `weak` and `unowned` for property declarations in a protocol.
13+
14+
Swift-evolution thread: [Ownership on protocol property requirements](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036495.html) thread.
15+
16+
## Motivation
17+
18+
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:
19+
20+
```swift
21+
22+
class A {}
23+
24+
protocol P {
25+
weak var weakVar: A? { get set }
26+
}
27+
28+
class B: P {
29+
var weakVar: A? // Not declared weak, no compiler warning/error
30+
}
31+
32+
```
33+
34+
This can lead to unexpected and surprising behaviour from the point of view of users. The keywords themselves are currently meaningless inside of a protocol but look like they would have an effect when the protocol is adopted.
35+
36+
This change is consistent with removing keywords that do not have any meaning like `final` in protocol extensions: [SE-0164](0164-remove-final-support-in-protocol-extensions.md).
37+
38+
## Proposed solution
39+
40+
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.
41+
42+
This proposal suggests removing support for `weak` and `unowned` in a protocol.
43+
44+
## Detailed design
45+
46+
In existing Swift modes, 3 and 4, the compiler will warn about the use of `weak` and `unowned` in a protocol and suggest a fix to remove the keywords. In Swift 5 mode the compiler will error and offer a fixit to remove the keywords.
47+
48+
## Source compatibility
49+
50+
This is a source breaking change but one that would only correct code that already has broken assumptions. For existing Swift modes, 3 and 4, the compiler will raise a compilation warning instead of an error.
51+
52+
## Effect on ABI stability
53+
54+
This proposal does not affect ABI stability.
55+
56+
## Effect on API resilience
57+
58+
This proposal does not affect API resilience.
59+
60+
## Alternatives considered
61+
62+
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.

0 commit comments

Comments
 (0)