Skip to content

Commit 44302dc

Browse files
committed
Add a Source Compatibility section to ST-0013 explaining motivation for keeping and deprecating the prior Issue.record() overload
1 parent 5a99e00 commit 44302dc

File tree

1 file changed

+30
-0
lines changed

1 file changed

+30
-0
lines changed

proposals/testing/0013-issue-severity-warning.md

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -152,6 +152,36 @@ For more details on `Issue`, refer to the [Issue Documentation](https://develope
152152

153153
This revision aims to clarify the functionality and usage of the `Severity` enum and `Issue` properties while maintaining consistency with the existing Swift API standards.
154154

155+
## Source compatibility
156+
157+
The aspect of this proposal which adds a new `severity:` parameter to the
158+
`Issue.record` function introduces the possibility of a source breakage for any
159+
clients who are capturing a reference to the function. Existing code could break
160+
despite the fact that the new parameter specifies a default value of `.error`.
161+
Here's a contrived example:
162+
163+
```
164+
// ❌ Source breakage due to new `Issue.Severity` parameter
165+
let myRecordFunc: (Comment?, SourceLocation) -> Issue = Issue.record
166+
```
167+
168+
To avoid source breakage, we will maintain the existing overload and preserve
169+
its signature, but mark it deprecated, disfavored, and hidden from documentation:
170+
171+
```swift
172+
extension Issue {
173+
// ...
174+
175+
@available(*, deprecated, message: "Use record(_:severity:sourceLocation:) instead.")
176+
@_disfavoredOverload
177+
@_documentation(visibility: private)
178+
@discardableResult public static func record(
179+
_ comment: Comment? = nil,
180+
sourceLocation: SourceLocation = #_sourceLocation
181+
) -> Self
182+
}
183+
```
184+
155185
### Integration with supporting tools
156186

157187
Issue severity will be in the event stream output when a `issueRecorded` event occurs. This will be a breaking change because some tools may assume that all `issueRecorded` events are failing. Due to this we will be bumping the event stream version and v1 will maintain it's behavior and not output any events for non failing issues. We will also be adding `isFailure` to the issue so that clients will know if the issue should be treated as a failure. `isFailure` is a computed property.

0 commit comments

Comments
 (0)