Skip to content

Commit 4c8612d

Browse files
committed
clarify existentials and do not propose any P<some ~Copyable>
1 parent b1a5637 commit 4c8612d

File tree

1 file changed

+27
-8
lines changed

1 file changed

+27
-8
lines changed

proposals/NNNN-suppressed-associated-types.md

Lines changed: 27 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -393,9 +393,9 @@ protocol Source<Element>: ~Copyable {
393393
}
394394
```
395395

396-
Existentials such as `any P` work similarly to a generic signature reified as
397-
a value, where the single generic parameter `T` has a conformance requirement
398-
`T: P`,
396+
Existentials such as `any P` work similarly to the case of a single generic
397+
parameter `T` has a conformance requirement `T: P`. The expansion of
398+
defaults happens here as well,
399399

400400
```swift
401401
func ex1(_ s: any Source) {
@@ -404,13 +404,12 @@ func ex1(_ s: any Source) {
404404
}
405405
```
406406

407-
> TODO: the following is not yet implemented!
408-
409-
It is possible to suppress the default requirement on an associated type using
410-
a new syntax `any Protocol<some Constraint>`:
407+
It's possible to constrain the existential using a generic type parameter,
408+
which will suppress the defaults expansion for the primary associated type of
409+
`Source`,
411410

412411
```swift
413-
func ex1(_ s: any Source<some ~Copyable>) {
412+
func ex2<R: ~Copyable>(_ s: any Source<R>) {
414413
let e = s.element() // <- NOT Copyable
415414
let g = s.generator() // <- NOT Copyable
416415
}
@@ -639,6 +638,26 @@ On the other hand, changing an associated type declaration in an library
639638
to suppress conformance is an ABI-breaking change, for similar reasons
640639
to those described above.
641640
641+
## Future Directions
642+
643+
It's possible to imagine additional functionality that could one day be
644+
supported, but is not part of this proposal.
645+
646+
### Constrained Existentials via `some`
647+
648+
There is some support for constrained existentials, such as
649+
650+
```swift
651+
func f<T: Hashable>(_ e: any P<T>) {}
652+
```
653+
654+
It might be a generally useful feature if there were support for a syntax such as
655+
`any P<some Hashable>` to permit the constrained existential to carry with it the
656+
constraint that its primary associated type conforms to Hashable.
657+
That syntax could then be extended to allow suppression of defaults in the
658+
constrained existential via `any Q<some ~Copyable>`.
659+
660+
642661
## Alternatives Considered
643662
644663
### No recursion

0 commit comments

Comments
 (0)