@@ -110,7 +110,7 @@ A new overload of `confirmation()` is added:
110
110
/// ``confirmation(_:expectedCount:isolation:sourceLocation:_:)`` instead.
111
111
public func confirmation <R >(
112
112
_ comment : Comment? = nil ,
113
- expectedCount : some RangeExpression<Int > & Sendable,
113
+ expectedCount : some RangeExpression<Int > & Sequence < Int > Sendable,
114
114
isolation : isolated (any Actor)? = #isolation ,
115
115
sourceLocation : SourceLocation = #_sourceLocation ,
116
116
_ body : (Confirmation) async throws -> sending R
@@ -121,22 +121,22 @@ public func confirmation<R>(
121
121
122
122
Certain types of range, specifically [ ` PartialRangeUpTo ` ] ( https://developer.apple.com/documentation/swift/partialrangeupto )
123
123
and [ ` PartialRangeThrough ` ] ( https://developer.apple.com/documentation/swift/partialrangethrough ) ,
124
- are valid when used with this new interface, but may have surprising behavior
125
- because they implicitly include ` 0 ` . If a test author writes ` ...10 ` , do they
126
- mean "zero to ten" or "one to ten"? The programmatic meaning is the former, but
127
- some test authors might mean the latter. If an event does not occur, a test
128
- using ` confirmation() ` and this ` expectedCount ` value would pass when the test
129
- author meant for it to fail.
130
-
131
- Swift Testing will attempt to detect these ambiguous uses of ` ...n ` and ` ..<n `
132
- expressions and diagnose them, recommending that test authors explicitly write
133
- ` 0 ` or ` 1 ` as a lower bound .
134
-
135
- ### Unbounded ranges
136
-
137
- Finally, an overload is added that takes an "unbounded range" (which is not
138
- technically a range at all, but… a closure?) This overload is marked unavailable
139
- because an unbounded range is effectively useless for testing :
124
+ may have surprising behavior when used with this new interface because they
125
+ implicitly include ` 0 ` . If a test author writes ` ...10 ` , do they mean "zero to
126
+ ten" or "one to ten"? The programmatic meaning is the former, but some test
127
+ authors might mean the latter. If an event does not occur, a test using
128
+ ` confirmation() ` and this ` expectedCount ` value would pass when the test author
129
+ meant for it to fail.
130
+
131
+ The unbounded range ( ` ... ` ) type ` UnboundedRange ` is effectively useless when
132
+ used with this interface and any use of it here is almost certainly a programmer
133
+ error .
134
+
135
+ ` PartialRangeUpTo ` and ` PartialRangeThrough ` conform to ` RangeExpression ` , but
136
+ not to ` Sequence ` , so they will be rejected at compile time. ` UnboundedRange ` is
137
+ a non-nominal type and will not match either. We will provide unavailable
138
+ overloads of ` confirmation() ` for these types with messages that explain why
139
+ they are unavailable, e.g. :
140
140
141
141
``` swift
142
142
@available (* , unavailable , message : " Unbounded range '...' has no effect when used with a confirmation." )
@@ -146,9 +146,7 @@ public func confirmation<R>(
146
146
isolation : isolated (any Actor)? = #isolation ,
147
147
sourceLocation : SourceLocation = #_sourceLocation ,
148
148
_ body : (Confirmation) async throws -> R
149
- ) async rethrows -> R {
150
- fatalError (" Unsupported" )
151
- }
149
+ ) async rethrows -> R
152
150
```
153
151
154
152
## Source compatibility
0 commit comments