[Accepted] SE-0156: Class and Subtype existentials


(Douglas Gregor) #1

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md

Hello Swift community,

The review of SE-0156 “Class and Subtype Existentials” ran from February 28...March 7, 2017. The proposal was very well-received and is accepted with one modification: the ordering rules for existential types that involve AnyObject or a class type will be removed.

The ordering rules were intended to improve code clarity by requiring that the class (or AnyObject) constraint come first—“AnyObject & P” would be well-formed but “P & AnyObject” would be an error—enforcing more uniformity for Swift code and echoing a similar restriction that already exists for class definitions, where the superclass must come first. However, the ability to compose typealiases complicated the ordering rules considerably, and—as noted by Matthew Johnson <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033365.html>—don’t provide the guarantee that the class constraint will always be first. Therefore, the core team felt that the resulting ordering rules introduced more complexity than they provided clarity, and therefore do not belong in the language.

  Thanks,
  Doug Gregor, Review Manager


(Karl) #2

Do we support where clauses on these existentials? For example, can I write:
  
func doSomething<T>(_: NSObject & Collection where Iterator.Element == T)
  
The proposal says nothing about where clauses.
  
- Karl

···

  
On Mar 20, 2017 at 7:00 pm, <Douglas Gregor via swift-evolution (mailto:swift-evolution@swift.org)> wrote:
  
Proposal link:

>
> https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md
>
  
Hello Swift community,

The review of SE-0156 “Class and Subtype Existentials” ran from February 28...March 7, 2017. The proposal was very well-received and is accepted with one modification: the ordering rules for existential types that involve AnyObject or a class type will be removed.

The ordering rules were intended to improve code clarity by requiring that the class (or AnyObject) constraint come first—“AnyObject & P” would be well-formed but “P & AnyObject” would be an error—enforcing more uniformity for Swift code and echoing a similar restriction that already exists for class definitions, where the superclass must come first. However, the ability to compose typealiases complicated the ordering rules considerably, and—as noted by Matthew Johnson (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033365.html)—don’t provide the guarantee that the class constraint will always be first. Therefore, the core team felt that the resulting ordering rules introduced more complexity than they provided clarity, and therefore do not belong in the language.
  
Thanks,
  
Doug Gregor, Review Manager
  
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution


(Douglas Gregor) #3

Do we support where clauses on these existentials? For example, can I write:

func doSomething<T>(_: NSObject & Collection where Iterator.Element == T)

The proposal says nothing about where clauses.

No, this proposal does not enable where clauses on existentials. That’s gone under the name “generalized existentials” or “enhanced existentials” as a separate (post-Swift-4) feature.

  - Doug

···

On Mar 22, 2017, at 7:12 AM, Karl Wagner <razielim@gmail.com> wrote:

- Karl

On Mar 20, 2017 at 7:00 pm, <Douglas Gregor via swift-evolution <mailto:swift-evolution@swift.org>> wrote:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0156-subclass-existentials.md

Hello Swift community,

The review of SE-0156 “Class and Subtype Existentials” ran from February 28...March 7, 2017. The proposal was very well-received and is accepted with one modification: the ordering rules for existential types that involve AnyObject or a class type will be removed.

The ordering rules were intended to improve code clarity by requiring that the class (or AnyObject) constraint come first—“AnyObject & P” would be well-formed but “P & AnyObject” would be an error—enforcing more uniformity for Swift code and echoing a similar restriction that already exists for class definitions, where the superclass must come first. However, the ability to compose typealiases complicated the ordering rules considerably, and—as noted by Matthew Johnson <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170227/033365.html>—don’t provide the guarantee that the class constraint will always be first. Therefore, the core team felt that the resulting ordering rules introduced more complexity than they provided clarity, and therefore do not belong in the language.

  Thanks,
  Doug Gregor, Review Manager

_______________________________________________ swift-evolution mailing list swift-evolution@swift.org <mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution