Skip to content

Commit d0f3525

Browse files
authored
Merge pull request #1083 from AnthonyLatsis/patch-6
[SE-0267] Some more legibility improvements
2 parents 2bcab0b + 9850ba8 commit d0f3525

File tree

1 file changed

+7
-8
lines changed

1 file changed

+7
-8
lines changed

proposals/0267-where-on-contextually-generic.md

Lines changed: 7 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -17,9 +17,9 @@ struct Box<Wrapped> {
1717

1818
```
1919

20-
> Only declarations that already support a generic parameter list and being constrained via a conditional
21-
> extension fall under this enhancement. Properties and hitherto unsupported constraint *kinds* are out
22-
> of scope for the proposal. For instance, the following remains an error:
20+
> Only declarations that already support a generic parameter list will be allowed to carry a `where` clause inside a generic
21+
> context. Generic properties and constraints on protocol requirements are out of scope for the current proposal.
22+
> For instance, the following remains an error:
2323
> ```swift
2424
> protocol P {
2525
> // error: Instance method requirement 'foo(arg:)' cannot add constraint 'Self: Equatable' on 'Self'
@@ -38,10 +38,9 @@ Swift-evolution thread: [Discussion thread topic for that proposal](https://foru
3838
## Motivation
3939
4040
Today, `where` clauses on contextually generic declarations, including protocol extension members, are expressed indirectly by placing them inside conditional extensions. Unless constraints are identical, every such declaration requires a separate extension.
41-
This dependence on extensions can be an obstacle to grouping semantically related APIs, stacking up constraints and,
42-
sometimes, the legibility of heavily generic interfaces.
41+
This dependence on extensions can be an obstacle to grouping semantically related APIs, stacking up constraints, and sometimes the legibility of heavily generic interfaces.
4342
44-
It is reasonable to expect a `where` clause to work anywhere a constraint can be meaningfully imposed, meaning both of these structuring styles should be available to the user:
43+
It is reasonable to expect a `where` clause to work anywhere a constraint can be meaningfully imposed, that is, both of these structuring styles should be available to the user:
4544
4645
```swift
4746
// 'Foo' can be any kind of nominal type declaration.
@@ -67,7 +66,7 @@ extension Foo where T: Sequence, T.Element: Equatable {
6766
}
6867
```
6968
A step towards generalizing `where` clause usage is an obvious and farsighted improvement to the generics
70-
system with numerous future applications, including [opaque types](https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md), [generalized
69+
system with numerous future applications, including generic properties, [opaque types](https://github.com/apple/swift-evolution/blob/master/proposals/0244-opaque-result-types.md), [generalized
7170
existentials](https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#generalized-existentials) and constrained protocol requirements.
7271
7372
## Source compatibility and ABI stability
@@ -76,4 +75,4 @@ This is an additive change with no impact on the ABI and existing code.
7675
7776
## Effect on API resilience
7877
79-
For public declarations in resilient libraries, moving a constraint from an extension to a member and vice versa will not be a source-breaking change, but will break the ABI due to subtle mangling differences.
78+
For public declarations in resilient libraries such as the Standard Library, moving a constraint from an extension to a member and vice versa will break the ABI due to subtle mangling differences as of the current implementation.

0 commit comments

Comments
 (0)