Similar observation on my side as well. Certainly it is better to specify the class constrain (or the type alias that has the class constrain) first because (sub)class constrain is the most determining factor about the nature of the declaration, but I think it is too hard to enforce properly when we have left type alias door wide open.
···
On Mar 1, 2017, at 12:01 PM, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto: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.
--
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:
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.
Same reasoning for class being the first in the inheritance/conformance list: it allows you to quickly read a list and see if there is a class where you expect it. The fact that one may come from a typealias is a different story: it's the difference between being able to quickly read an expression and understanding the whole function it's contained in.
···
On 1 Mar 2017, at 21:01, Matthew Johnson via swift-evolution <swift-evolution@swift.org> wrote:
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> 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
Is the problem being addressed significant enough to warrant a change to
Swift?
Yes
Does this proposal fit well with the feel and direction of Swift?
Yes
How much effort did you put into your review? A glance, a quick reading, or
an in-depth study?
I've followed the thread and gave the proposal a quick reading.
This has reminded me that we are still without a means to specify that a
type have value semantics, though.
···
On Fri, Mar 3, 2017 at 9:39 AM, Adrian Zubarev via swift-evolution < swift-evolution@swift.org> wrote:
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.
I don't think there's any added complexity alone in allowing generic base class constraints in existentials, since we already support `<T: C<U>>` as a constraint on a generic parameter. It's the interaction between classes and protocols with associated types that's interesting. You don't even need a generic class:
protocol P { associatedtype T; func foo(_: T) }
class C: P { func foo(_: Int) {} }
protocol Q: P {}
let x: C & Q
-Joe
···
On Feb 28, 2017, at 10:39 PM, David Hart <david@hartbit.com> wrote:
On 28 Feb 2017, at 22:53, Jordan Rose via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
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.
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.
Same reasoning for class being the first in the inheritance/conformance list: it allows you to quickly read a list and see if there is a class where you expect it. The fact that one may come from a typealias is a different story: it's the difference between being able to quickly read an expression and understanding the whole function it's contained in.
Yep, I understand this. The difference is that in the inheritance list if there is a class present it must always be explicitly declared. This means you can always tell whether a class is involved by looking at the first item in the list. That is not the case when existential are composed. If you can’t rely on this in all cases the limitation feels somewhat arbitrary.
That said, it’s not a big deal. I appreciate the proposal very much! :)
···
On Mar 1, 2017, at 2:16 PM, David Hart <david@hartbit.com> wrote:
On 1 Mar 2017, at 21:01, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto: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
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.
Same reasoning for class being the first in the inheritance/conformance list: it allows you to quickly read a list and see if there is a class where you expect it. The fact that one may come from a typealias is a different story: it's the difference between being able to quickly read an expression and understanding the whole function it's contained in.
Yep, I understand this. The difference is that in the inheritance list if there is a class present it must always be explicitly declared. This means you can always tell whether a class is involved by looking at the first item in the list. That is not the case when existential are composed. If you can’t rely on this in all cases the limitation feels somewhat arbitrary.
That said, it’s not a big deal. I appreciate the proposal very much! :)
Yeah, it’s a detail :) Just trying to describe my thought process.
···
On 1 Mar 2017, at 21:20, Matthew Johnson <matthew@anandabits.com> wrote:
On Mar 1, 2017, at 2:16 PM, David Hart <david@hartbit.com <mailto:david@hartbit.com>> wrote:
On 1 Mar 2017, at 21:01, Matthew Johnson via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Mar 1, 2017, at 1:59 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto: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