Skip to content

Update statuses of generic proposals #12038

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Sep 25, 2017
Merged

Update statuses of generic proposals #12038

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0caa44e
Update statuses of generic proposals
BasThomas Sep 21, 2017
0e6bb98
Update SE-0157 status
BasThomas Sep 21, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions docs/GenericsManifesto.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,7 +27,7 @@ There are a number of restrictions to the use of generics that fall out of the i

### Recursive protocol constraints (*)

*The feature is being reviewed in [SE-0157](https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md).*
*This feature has been accepted in [SE-0157](https://github.com/apple/swift-evolution/blob/master/proposals/0157-recursive-protocol-constraints.md) and is tracked by [SR-1445](https://bugs.swift.org/browse/SR-1445).*

Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For example, in the standard library `SubSequence` type of a `Sequence` should itself be a `Sequence`:

Expand All @@ -43,7 +43,7 @@ The compiler currently rejects this protocol, which is unfortunate: it effective

### Nested generics

*This feature is tracked by [SR-1446](https://bugs.swift.org/browse/SR-1446) and is planned for release with Swift 3.1.*
*This feature was tracked by [SR-1446](https://bugs.swift.org/browse/SR-1446) and was released with Swift 3.1.*

Currently, a generic type cannot be nested within another generic type, e.g.

Expand All @@ -57,7 +57,7 @@ There isn't much to say about this: the compiler simply needs to be improved to

### Concrete same-type requirements

*This feature is tracked by [SR-1009](https://bugs.swift.org/browse/SR-1009) and is planned for release with Swift 3.1.*
*This feature was tracked by [SR-1009](https://bugs.swift.org/browse/SR-1009) and was released with Swift 3.1.*

Currently, a constrained extension cannot use a same-type constraint to make a type parameter equivalent to a concrete type. For example:

Expand Down Expand Up @@ -90,7 +90,7 @@ var d2: Dictionary<String, Int> = d1 // okay: d1 and d2 have the same type, Dict

### Generic subscripts

*This feature has been accepted in [SE-0148](https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md), is tracked by [SR-115](https://bugs.swift.org/browse/SR-115) and is planned for release in Swift 4.*
*This feature has been accepted in [SE-0148](https://github.com/apple/swift-evolution/blob/master/proposals/0148-generic-subscripts.md), was tracked by [SR-115](https://bugs.swift.org/browse/SR-115) and was released with Swift 4.*

Subscripts could be allowed to have generic parameters. For example, we could introduce a generic subscript on a `Collection` that allows us to pull out the values at an arbitrary set of indices:

Expand Down Expand Up @@ -186,7 +186,7 @@ There are a number of minor extensions we can make to the generics system that d

### Arbitrary requirements in protocols (*)

*This feature has been accepted in [SE-0142](https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md) and is under development.*
*This feature has been accepted in [SE-0142](https://github.com/apple/swift-evolution/blob/master/proposals/0142-associated-types-constraints.md) and was released with Swift 4.*

Currently, a new protocol can inherit from other protocols, introduce new associated types, and add new conformance constraints to associated types (by redeclaring an associated type from an inherited protocol). However, one cannot express more general constraints. Building on the example from "Recursive protocol constraints", we really want the element type of a `Sequence`'s `SubSequence` to be the same as the element type of the `Sequence`, e.g.,

Expand All @@ -202,7 +202,7 @@ Hanging the `where` clause off the associated type protocol is not ideal, but th

### Typealiases in protocols and protocol extensions (*)

*The feature has been accepted in [SE-0092](https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md) and was released with Swift 3.*
*This feature has been accepted in [SE-0092](https://github.com/apple/swift-evolution/blob/master/proposals/0092-typealiases-in-protocols.md) and was released with Swift 3.*

Now that associated types have their own keyword (thanks!), it's reasonable to bring back `typealias`. Again with the `Sequence` protocol:

Expand All @@ -229,7 +229,7 @@ var p3: Promise = getRandomPromise() // p3 has type Promise<Int, Error> due to t

### Generalized `class` constraints

*This feature will come as a consequence of proposal [SE-0156](https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md) which is in review.*
*This feature will come as a consequence of proposal [SE-0156](https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md) and was released with Swift 4.*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/will come as/is/

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll fix this with a follow-up PR.


The `class` constraint can currently only be used for defining protocols. We could generalize it to associated type and type parameter declarations, e.g.,

Expand Down Expand Up @@ -691,7 +691,7 @@ The generics system doesn't seem like a good candidate for a reduction in scope;

### Associated type inference

*The feature has been rejected in [SE-0108](https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md).*
*This feature has been rejected in [SE-0108](https://github.com/apple/swift-evolution/blob/master/proposals/0108-remove-assoctype-inference.md).*

Associated type inference is the process by which we infer the type bindings for associated types from other requirements. For example:

Expand Down