Skip to content

Commit e18eae1

Browse files
author
Greg Spiers
committed
Add draft proposal for ownership keyword removal in protocols.
1 parent ad8fce4 commit e18eae1

File tree

1 file changed

+61
-0
lines changed

1 file changed

+61
-0
lines changed
Lines changed: 61 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,61 @@
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+
* Bug: [SR-479](https://bugs.swift.org/browse/SR-479)
8+
9+
## Introduction
10+
11+
This proposal removes support for the keywords `weak` and `unowned` for property declarations in a protocol.
12+
13+
Swift-evolution thread: [Ownership on protocol property requirements](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170501/036495.html) thread.
14+
15+
## Motivation
16+
17+
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:
18+
19+
```swift
20+
21+
class A {}
22+
23+
protocol P {
24+
weak var weakVar: A? { get set }
25+
}
26+
27+
class B: P {
28+
var weakVar: A? // Not declared weak, no compiler warning/error
29+
}
30+
31+
```
32+
33+
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.
34+
35+
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).
36+
37+
## Proposed solution
38+
39+
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.
40+
41+
This proposal suggests removing support for `weak` and `unowned` in a protocol.
42+
43+
## Detailed design
44+
45+
The compiler will flag the use of `weak` and `unowned` in a protocol and suggest a fix to remove the keyword.
46+
47+
## Source compatibility
48+
49+
This is a source breaking change but one that would only correct code that 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.
50+
51+
## Effect on ABI stability
52+
53+
This proposal does not affect ABI stability.
54+
55+
## Effect on API resilience
56+
57+
This proposal should not effect API resilience.
58+
59+
## Alternatives considered
60+
61+
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)