The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
Well-written, good job, useful feature, long-since-needed-because-of-ObjC, +1.
One nitpick:
This proposal merges the concepts of `class` and `AnyObject`, which now have the same meaning: they represent an existential for classes. To get rid of the duplication, we suggest only keeping `AnyObject` around. To reduce source-breakage to a minimum, `class` could be redefined as `typealias class = AnyObject` and give a deprecation warning on `class` for the first version of Swift this proposal is implemented in. Later, `class` could be removed in a subsequent version of Swift.
'class' is a keyword, so we don't get to drop the special parsing no matter what. We can still deprecate it, but I wouldn't bother trying to jam it into a typealias.
Composing a base class and protocol requirements opens up the possibility of using the base class to constrain away a protocol's associated types, e.g.:
protocol P { associatedtype T; func foo(_: T) }
class C<T>: P { func foo(_: T) {}
It'd be worth calling out explicitly whether this proposal allows `C<T> & P` to be used as an existential type, since although P has free associated types, the composition does not.
-Joe
···
On Feb 28, 2017, at 1:11 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
What is your evaluation of the proposal?
It seems to be a very straightforward and natural extension of existing syntax to bring Swift closer to the functionality of Objective-C and other languages.
My only concern is that using `AnyObject` at first glance seems less descriptive than ‘class’ when used in a protocol declaration, but it may be simply because I already familiar with the `class` syntax.
Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely.
Does this proposal fit well with the feel and direction of Swift?
Yes. It is a sensible extension to existing patters. Eliminating the redundancy and ambiguity in `class` and `AnyObject` eliminates a barrier to understanding the language and is probably worth the pain of deprecating `class` which I have used extensively in my code.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I have used the feature numerous times in Objective-C over the years and this proposal is a perfect analog as far as I know.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I gave the proposal a thorough reading. It is straightforward enough to not require much study.
···
On Feb 28, 2017, at 2:11 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
The proposal does not specifically call out whether a class may inherit from a subclass of a superclass constraint when a typealias is used in the inheritance list. I believe the following should be valid, but it would be a good idea to make that explicit:
class B {}
class D: B {}
protocol P {}
typealias BP = B & P
class Foo: D, BP
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, we are not able to correctly import class constrained protocols from Objective-C.
Does this proposal fit well with the feel and direction of Swift?
Very much.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study of the original drafts. Quick read of the final review proposal.
+0.9
The core of the proposal is unquestionably necessary to correct a serious deficiency in the expressivity of the type system, but I take issue with the arbitrary limitation of requiring the concrete type to be first and would give a full +1 to the core team accepting with the modification of removing that limitation.
Is the problem being addressed significant enough to warrant a change to Swift?
Definitely. I’ve run into the issue this would solve several times in real-world applications.
Does this proposal fit well with the feel and direction of Swift?
Yes
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Basically a direct translation of the objc feature.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
Followed and to some extent participated in the discussion, relatively quick read of the final proposal.
This is a critical must have feature in Swift. I’ve been waiting for it since Swift 1.2.
2) Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely.
3) Does this proposal fit well with the feel and direction of Swift?
No doubt.
4) If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Yes in Objective-C. This proposal does not add the where clause to existentials yet, but it leaves the door open to add that in the future, which would make the feature even more powerful.
5) How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I originally pitched the idea of class existentials calling them type<A,B> compared to the old style protocol<A,B> in 2016. Then I tracked every topic about existentials on the mailing list. And I carefully read every pitch and proposal including existentials.
A good and necessary enhancement. My only objection is to the ordering rules—I'm not convinced that they pull their weight, especially given that typealiases can be used to introduce class constraints that aren't in the leftmost position. It's a lot of rules and strictures for a dubious benefit.
···
--
Brent Royal-Gordon
Sent from my iPhone
On Feb 28, 2017, at 1:11 PM, Douglas Gregor <dgregor@apple.com> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
Using ": class" always felt wrong for me — but only because of the convention that type names should start uppercase:
What is wrong with "Class" instead of "AnyObject"?
Object is a very broad term, and it isn't that uncommon to use it for all kinds of entities (not only reference types).
And what if we ever decide that restricting protocols to structs or enums should be allowed as well?
Or maybe there are secret plans to add new reference types to Swift? ;-)
Nitpick: 'C<T> & P' is just 'C<T>' in this example. You'd need a refinement of 'P' to make it interesting ('C<T> & Q').
Jordan
···
On Feb 28, 2017, at 13:20, Joe Groff via swift-evolution <swift-evolution@swift.org> wrote:
Composing a base class and protocol requirements opens up the possibility of using the base class to constrain away a protocol's associated types, e.g.:
protocol P { associatedtype T; func foo(_: T) }
class C<T>: P { func foo(_: T) {}
It'd be worth calling out explicitly whether this proposal allows `C<T> & P` to be used as an existential type, since although P has free associated types, the composition does not.
-Joe
On Feb 28, 2017, at 1:11 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
Well-written, good job, useful feature, long-since-needed-because-of-ObjC, +1.
One nitpick:
This proposal merges the concepts of `class` and `AnyObject`, which now have the same meaning: they represent an existential for classes. To get rid of the duplication, we suggest only keeping `AnyObject` around. To reduce source-breakage to a minimum, `class` could be redefined as `typealias class = AnyObject` and give a deprecation warning on `class` for the first version of Swift this proposal is implemented in. Later, `class` could be removed in a subsequent version of Swift.
'class' is a keyword, so we don't get to drop the special parsing no matter what. We can still deprecate it, but I wouldn't bother trying to jam it into a typealias.
Yes. I only meant to drop its meaning as a class-type constraint.
···
On 28 Feb 2017, at 22:19, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
The proposal does not specifically call out whether a class may inherit from a subclass of a superclass constraint when a typealias is used in the inheritance list. I believe the following should be valid, but it would be a good idea to make that explicit:
class B {}
class D: B {}
protocol P {}
typealias BP = B & P
class Foo: D, BP
It’s true that the proposal is not very clear about that specific scenario, but I see it as valid. I touched about it in the “inheritance clauses and typealias” section but only mentioned inheritance from the class in the constraint. But rule 2 of the proposal kind of implies it: the first element in the protocol composition syntax can be a class type to enforce the existential to be a subtype of the class.
It would be worth being more precise about it, but not sure how a proposal can be *fixed* during review.
···
On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, we are not able to correctly import class constrained protocols from Objective-C.
Does this proposal fit well with the feel and direction of Swift?
Very much.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study of the original drafts. Quick read of the final review proposal.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
What is your evaluation of the proposal?
It seems to be a very straightforward and natural extension of existing syntax to bring Swift closer to the functionality of Objective-C and other languages.
My only concern is that using `AnyObject` at first glance seems less descriptive than ‘class’ when used in a protocol declaration, but it may be simply because I already familiar with the `class` syntax.
To be honest, I didn’t feel very strongly either way. But using class would make the following syntax valid and weird:
let a: class = Object()
So I followed the road of Objective-C, which uses the type generic class type (AnyObject) as the class constraint keyword.
···
On 28 Feb 2017, at 22:52, Christopher Kornher via swift-evolution <swift-evolution@swift.org> wrote:
Is the problem being addressed significant enough to warrant a change to Swift?
Absolutely.
Does this proposal fit well with the feel and direction of Swift?
Yes. It is a sensible extension to existing patters. Eliminating the redundancy and ambiguity in `class` and `AnyObject` eliminates a barrier to understanding the language and is probably worth the pain of deprecating `class` which I have used extensively in my code.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
I have used the feature numerous times in Objective-C over the years and this proposal is a perfect analog as far as I know.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I gave the proposal a thorough reading. It is straightforward enough to not require much study.
On Feb 28, 2017, at 2:11 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
Well-written, good job, useful feature, long-since-needed-because-of-ObjC, +1.
One nitpick:
This proposal merges the concepts of `class` and `AnyObject`, which now have the same meaning: they represent an existential for classes. To get rid of the duplication, we suggest only keeping `AnyObject` around. To reduce source-breakage to a minimum, `class` could be redefined as `typealias class = AnyObject` and give a deprecation warning on `class` for the first version of Swift this proposal is implemented in. Later, `class` could be removed in a subsequent version of Swift.
'class' is a keyword, so we don't get to drop the special parsing no matter what. We can still deprecate it, but I wouldn't bother trying to jam it into a typealias.
Yeah, why bother making
typealias class = AnyObject
compile?
We should just provide autocorrect to migrate this:
protocol P: class {}
into this:
protocol P: AnyObject {}
and warn if the old syntax is used (while continuing to support it just as it works now). We can then remove the parser rules that accept the first form (using ‘class’) in Swift 5.
Otherwise strong +1 as it is obviously needed for proper ObjC support.
···
On Feb 28, 2017, at 1:19 PM, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
A good and necessary enhancement. My only objection is to the ordering rules—I'm not convinced that they pull their weight, especially given that typealiases can be used to introduce class constraints that aren't in the leftmost position. It's a lot of rules and strictures for a dubious benefit.
I made a similar comment in the discussion thread. I don’t feel strongly enough to argue over it, but it does feel like a rather arbitrary limitation.
···
On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
--
Brent Royal-Gordon
Sent from my iPhone
On Feb 28, 2017, at 1:11 PM, Douglas Gregor <dgregor@apple.com <mailto:dgregor@apple.com>> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
And what if we ever decide that restricting protocols to structs or enums should be allowed as well?
AnyValue (_might_ happen with value sub typing)?
Or maybe there are secret plans to add new reference types to Swift?
Classes aren’t the only reference types in Swift, functions are also reference types, but there is no way to express something like _any function_.
The question is, if the *new* reference types will be objects or something different. Otherwise we’ll simply need to add AnyReference or something similar to that.
There was a huuuuge talk about AnyValue vs. AnyObject last year, and I’m totally convinced with AnyObject. The Any prefix also indicates that it’s an existential which is correct in this context.
The proposal does not specifically call out whether a class may inherit from a subclass of a superclass constraint when a typealias is used in the inheritance list. I believe the following should be valid, but it would be a good idea to make that explicit:
class B {}
class D: B {}
protocol P {}
typealias BP = B & P
class Foo: D, BP
It’s true that the proposal is not very clear about that specific scenario, but I see it as valid. I touched about it in the “inheritance clauses and typealias” section but only mentioned inheritance from the class in the constraint. But rule 2 of the proposal kind of implies it: the first element in the protocol composition syntax can be a class type to enforce the existential to be a subtype of the class.
It would be worth being more precise about it, but not sure how a proposal can be *fixed* during review.
I think proposals have occasionally seen this kind of clarification during review. In any case, thanks for confirming your intent. I just wanted to make sure this is what you expected also.
···
On Feb 28, 2017, at 4:14 PM, David Hart <david@hartbit.com> wrote:
On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Is the problem being addressed significant enough to warrant a change to Swift?
Yes, we are not able to correctly import class constrained protocols from Objective-C.
Does this proposal fit well with the feel and direction of Swift?
Very much.
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
N/A
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
In-depth study of the original drafts. Quick read of the final review proposal.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org> https://lists.swift.org/mailman/listinfo/swift-evolution
Yeah, I don't see any problem clarifying intent and making minor revisions to the proposal in response to review feedback.
-Joe
···
On Feb 28, 2017, at 2:28 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Feb 28, 2017, at 4:14 PM, David Hart <david@hartbit.com> wrote:
On 28 Feb 2017, at 22:45, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
• What is your evaluation of the proposal?
+1, this is a fantastic proposal! I
The proposal does not specifically call out whether a class may inherit from a subclass of a superclass constraint when a typealias is used in the inheritance list. I believe the following should be valid, but it would be a good idea to make that explicit:
class B {}
class D: B {}
protocol P {}
typealias BP = B & P
class Foo: D, BP
It’s true that the proposal is not very clear about that specific scenario, but I see it as valid. I touched about it in the “inheritance clauses and typealias” section but only mentioned inheritance from the class in the constraint. But rule 2 of the proposal kind of implies it: the first element in the protocol composition syntax can be a class type to enforce the existential to be a subtype of the class.
It would be worth being more precise about it, but not sure how a proposal can be *fixed* during review.
I think proposals have occasionally seen this kind of clarification during review. In any case, thanks for confirming your intent. I just wanted to make sure this is what you expected also.
Nitpick: 'C<T> & P' is just 'C<T>' in this example. You'd need a refinement of 'P' to make it interesting ('C<T> & Q').
Jordan
Or conformance to P needs to be conditional.
That is my only issue with this proposal: why limit it to class types? I think it needs to be generalised to allow all concrete type + protocol existentials, in order to make conditional conformances useful.
For example, let’s say I have a type “MyStruct” which conditionally conforms to “MyProtocol":
protocol MyProtocol { … }
struct MyStruct<T: Something> { … }
// Conditional conformance to MyProtocol
extension MyStruct: MyProtocol where T.AnAssociatedType == SomeType, T.AnotherAssociatedType: SomeOtherProtocol /* ...etc */ { … }
Now, I want a conforming struct. How am I supposed to do that? I think the most logical way is to write:
var conformingStruct: MyStruct & MyProtocol
… which is the generalisation of what is being talked about here.
Sorry if that’s broadened the scope too much.
- Karl
···
On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
On Feb 28, 2017, at 13:20, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Composing a base class and protocol requirements opens up the possibility of using the base class to constrain away a protocol's associated types, e.g.:
protocol P { associatedtype T; func foo(_: T) }
class C<T>: P { func foo(_: T) {}
It'd be worth calling out explicitly whether this proposal allows `C<T> & P` to be used as an existential type, since although P has free associated types, the composition does not.
-Joe
On Feb 28, 2017, at 1:11 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at
Nitpick: 'C<T> & P' is just 'C<T>' in this example. You'd need a refinement of 'P' to make it interesting ('C<T> & Q’).
Could generic specialisation be disallowed in constraints? I need to think about this.
···
On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution <swift-evolution@swift.org> wrote:
Jordan
On Feb 28, 2017, at 13:20, Joe Groff via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Composing a base class and protocol requirements opens up the possibility of using the base class to constrain away a protocol's associated types, e.g.:
protocol P { associatedtype T; func foo(_: T) }
class C<T>: P { func foo(_: T) {}
It'd be worth calling out explicitly whether this proposal allows `C<T> & P` to be used as an existential type, since although P has free associated types, the composition does not.
-Joe
On Feb 28, 2017, at 1:11 PM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Hello Swift community,
The review of SE-0156 "Class and Subtype existentials" begins now and runs through March 7, 2017. The proposal is available here:
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:
• What is your evaluation of the proposal?
• Is the problem being addressed significant enough to warrant a change to Swift?
• Does this proposal fit well with the feel and direction of Swift?
• If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at