Re: [swift-evolution] Subclass Existentials

> On 3 Feb 2017, at 18:12, Douglas Gregor via swift-evolution > wrote: > >> >> On Feb 2, 2017, at 3:24 PM, David Hart > > wrote: >> >>> >>> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] Subclass Existentials

> On Feb 6, 2017, at 11:30 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Feb 5, 2017, at 3:20 PM, David Hart > > wrote: >> >> As they are heavily linked, should a change like this be included in the >>

Re: [swift-evolution] Subclass Existentials

> On Feb 5, 2017, at 3:20 PM, David Hart wrote: > > As they are heavily linked, should a change like this be included in the > superclass + class proposal or separately? > > I'm heavily tending towards (1), and redefining: > > typealias Any = Any<> > typealias AnyObject =

Re: [swift-evolution] Subclass Existentials

As they are heavily linked, should a change like this be included in the superclass + class proposal or separately? I'm heavily tending towards (1), and redefining: typealias Any = Any<> typealias AnyObject = Any Does that sound reasonable to you? Just checking before I rewrite this proposal

Re: [swift-evolution] Subclass Existentials

> On Feb 2, 2017, at 3:24 PM, David Hart wrote: > >> >> On 3 Feb 2017, at 00:04, Douglas Gregor via swift-evolution >> > wrote: >> >> >>> On Feb 2, 2017, at 2:54 PM, David Smith >>

Re: [swift-evolution] Subclass Existentials

> On Feb 2, 2017, at 2:54 PM, David Smith wrote: > >> >> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution >> > wrote: >> >> >>> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev >>>

Re: [swift-evolution] Subclass Existentials

> On Feb 2, 2017, at 11:20 AM, Douglas Gregor via swift-evolution > wrote: > > >> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev > > wrote: >> >> typealias AnyObject = … is nice to have, but

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 11:44 PM, Adrian Zubarev > wrote: > > typealias AnyObject = … is nice to have, but how about if we fully drop the > class constraint-keyword and generalize AnyObject instead? > That’s a good point. My *technical* goal is for AnyObject to

Re: [swift-evolution] Subclass Existentials

It's pretty bizarre that conforming to `protocol P: Q {}` requires an explicit conformance to Q when Q is a class but not when Q is a protocol. It's the same syntax, but conformance is only "inherited" for protocols. > On Feb 1, 2017, at 3:47 PM, Matthew Johnson via swift-evolution >

Re: [swift-evolution] Subclass Existentials

typealias AnyObject = … is nice to have, but how about if we fully drop the class constraint-keyword and generalize AnyObject instead? In the future we might want to add AnyValue with value (semantics) constraint, would that mean that we’d need another keyword there like value? The former is

Re: [swift-evolution] Subclass Existentials

Sent from my iPhone > On Feb 1, 2017, at 8:46 PM, Slava Pestov wrote: > > >>> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution >>> wrote: >>> >>> >>> On Feb 1, 2017, at 3:13 PM, David Hart wrote: >>> >>>

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 4:09 PM, Douglas Gregor via swift-evolution > wrote: > >> >> On Feb 1, 2017, at 3:13 PM, David Hart > > wrote: >> >> Second question inline: >> >> >> >> Sent from my iPhone >> On 1 Feb 2017, at

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 4:06 PM, Douglas Gregor wrote: > > Personally, I like having the requirement that the class come first. It fits > with the requirement we already have for classes that have a superclass. I guess I’ll throw my hat into the ring and +1 this too. What if

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 3:13 PM, David Hart wrote: > > Second question inline: > > > > Sent from my iPhone > On 1 Feb 2017, at 23:09, David Hart > wrote: > >> I did consider it, but didn’t want to put too much on your plate for

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 2:09 PM, David Hart wrote: > > I did consider it, but didn’t want to put too much on your plate for Swift 4. Quite appreciated! Cleaning up AnyObject happens to be on my list of ABI-impacting changes I’m itching to make ;) > But if you’re mentioning

Re: [swift-evolution] Subclass Existentials

I did consider it, but didn’t want to put too much on your plate for Swift 4. But if you’re mentioning it, I’ll go ahead and add it to the second version of the proposal. By the way, what you is your point of view about the discussions we’ve had concerning the positioning of the class

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 15:17, David Hart wrote: > > > On 2 Feb 2017, at 00:06, Jordan Rose > wrote: > >> I agree with Chris on both counts. Either we need to continue to import >> ‘NSFoo *’ as ‘NSFoo’ in the Swift 4

Re: [swift-evolution] Subclass Existentials

> On 2 Feb 2017, at 00:06, Jordan Rose wrote: > > I agree with Chris on both counts. Either we need to continue to import > ‘NSFoo *’ as ‘NSFoo’ in the Swift 4 compiler’s “Swift 3 compatibility > mode”, or we need to come up with all the cases where a normally-unsound

Re: [swift-evolution] Subclass Existentials

I agree with Chris on both counts. Either we need to continue to import ‘NSFoo *’ as ‘NSFoo’ in the Swift 4 compiler’s “Swift 3 compatibility mode”, or we need to come up with all the cases where a normally-unsound conversion needs to be permitted (possibly with a warning) in order to avoid

Re: [swift-evolution] Subclass Existentials

> On Feb 1, 2017, at 3:01 PM, David Hart via swift-evolution > wrote: > > > On 1 Feb 2017, at 22:54, Douglas Gregor > wrote: > >> >>> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution >>>

Re: [swift-evolution] Subclass Existentials

> On 1 Feb 2017, at 22:54, Douglas Gregor wrote: > > >> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution >> wrote: >> >> This is a nice generalization of the existing protocol composition syntax. >> Implementation might get a

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 8:39 AM, David Hart wrote: > > Hello, > > As promised, I wrote the first draft of a proposal to add class requirements > to the existential syntax. Please let me know what you think. > >

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 8:44 PM, Slava Pestov via swift-evolution > wrote: > > This is a nice generalization of the existing protocol composition syntax. > Implementation might get a little tricky — this touches a lot of things, such > as inheritance clauses,

Re: [swift-evolution] Subclass Existentials

> On 29 Jan 2017, at 23:12, Xiaodi Wu wrote: > >> On Sun, Jan 29, 2017 at 4:01 PM, David Hart via swift-evolution >> wrote: >> Hi Matthew, >> >> I’ll reply to this post, because it allows me to discuss a few of the points >> in the discussion,

Re: [swift-evolution] Subclass Existentials

Given that supporting value subtyping or self-conforming existentials in the future would not be a code-breaking change AFAICT, I don't think it makes sense to spend much energy discussing it now. If we do end up getting value subtyping for Swift 4, we can have a compiler engineer estimate how

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 10:47 PM, Slava Pestov wrote: > > >> On Jan 29, 2017, at 2:05 PM, Matthew Johnson via swift-evolution >> > wrote: >> >>> >>> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu >>

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:05 PM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu > > wrote: >> >> On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson

Re: [swift-evolution] Subclass Existentials

This is a nice generalization of the existing protocol composition syntax. Implementation might get a little tricky — this touches a lot of things, such as inheritance clauses, constraints in generic signatures, and casts. It would require thorough testing. There are also a few odd corner

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 6:00 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 4:48 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> On Jan 29, 2017, at 4:01

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 4:48 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution > > wrote: > >> On Jan 29, 2017, at 4:01 PM, David Hart >

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > On Jan 29, 2017, at 4:01 PM, David Hart wrote: > > Hi Matthew, > > I’ll reply to this post, because it allows me to discuss a few of the > points in the discussion, but

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 4:01 PM, David Hart wrote: > > Hi Matthew, > > I’ll reply to this post, because it allows me to discuss a few of the points > in the discussion, but I’ve read the whole discussion. > >> On 29 Jan 2017, at 18:30, Matthew Johnson

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 4:01 PM, David Hart via swift-evolution < swift-evolution@swift.org> wrote: > Hi Matthew, > > I’ll reply to this post, because it allows me to discuss a few of the > points in the discussion, but I’ve read the whole discussion. > > On 29 Jan 2017, at 18:30, Matthew Johnson

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:52 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 3:35 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 3:24 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

Hi Matthew, I’ll reply to this post, because it allows me to discuss a few of the points in the discussion, but I’ve read the whole discussion. > On 29 Jan 2017, at 18:30, Matthew Johnson wrote: > > Hi David, > > This looks like a great start. > > One thing we should

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:24 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 3:11 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 3:05 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 2:40 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 2:25 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson > wrote: > >> >> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:25 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson > wrote: > >> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu > > wrote:

Re: [swift-evolution] Subclass Existentials

+1 on the proposal, but this shows why mixing classes and protocols like so just confuses things... classOrStructOrThingyOhIMissYouNSProxy Gave the separation we needed, but then withGenerics this becomes a bit worse to handle... Sent from my

Re: [swift-evolution] Subclass Existentials

Can I say that I dearly miss the old Any<> syntax? Oh well... Sent from my iPhone > On 29 Jan 2017, at 18:41, Austin Zheng via swift-evolution > wrote: > > The "class comes first" requirement made more sense when the proposed syntax > was still "Any",

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 2:16 PM, Matthew Johnson wrote: > > On Jan 29, 2017, at 2:01 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Jan 29, 2017, at

Re: [swift-evolution] Subclass Existentials

+1 on the proposal overall. You might want to clarify the writing wrt source compatibility though. The new syntax and type system mechanics should work in Swift 3 mode, it is just the importer change that must be conditionalized. -Chris > On Jan 29, 2017, at 8:39 AM, David Hart via

Re: [swift-evolution] Subclass Existentials

> On Jan 29, 2017, at 2:01 PM, Xiaodi Wu wrote: > > On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson > wrote: > > > Sent from my iPad > > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution >

Re: [swift-evolution] Subclass Existentials

Sorry, I meant to say for the same reason they are required to be first in class inheritance/conformance clauses. -Chris > On Jan 29, 2017, at 12:14 PM, Chris Lattner wrote: > > I think it makes sense to require class bounds to be first, for the same > reason they must be

Re: [swift-evolution] Subclass Existentials

I think it makes sense to require class bounds to be first, for the same reason they must be first in. Lass inheritance clauses: to encourage consistency and make it more clear when some type has an ambiguous name (which shouldn't happen, but...) -Chris > On Jan 29, 2017, at 9:03 AM, Kevin

Re: [swift-evolution] Subclass Existentials

On Sun, Jan 29, 2017 at 1:37 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > Cool. Another avenue of improvement here is relaxing the single-class > spelling rule

Re: [swift-evolution] Subclass Existentials

Sent from my iPad > On Jan 29, 2017, at 12:58 PM, Xiaodi Wu via swift-evolution > wrote: > > Cool. Another avenue of improvement here is relaxing the single-class > spelling rule for the sake of composing typealiases. > > As Matthew mentioned, if I have class

Re: [swift-evolution] Subclass Existentials

Cool. Another avenue of improvement here is relaxing the single-class spelling rule for the sake of composing typealiases. As Matthew mentioned, if I have class Base and typealiases Foo = Base & Protocol1 and Bar = Base & Protocol2, it'd be nice to allow Foo & Bar. It'd be nice to go one step

Re: [swift-evolution] Subclass Existentials

The "class comes first" requirement made more sense when the proposed syntax was still "Any", intentionally mirroring how the superclass and conformances are declared on a class declaration (the archives contain more detailed arguments, both pro and con). Now that the syntax is "T & U

Re: [swift-evolution] Subclass Existentials

As Matthew mentioned, the rules can certainly later be relaxed, but given that this proposal has the compiler generating fix-its for subclasses in second position, is there a reason other than stylistic for demanding MyClass & MyProtocol instead of MyProtocol & MyClass? From a naive perspective,

Re: [swift-evolution] Subclass Existentials

Hi David, This looks like a great start. One thing we should consider is whether we tie this proposal so tightly to classes or whether it might be better to call these supertype constraints. The feature might also be useful for value types if / when Swift gets value subtyping. One

Re: [swift-evolution] Subclass Existentials

+1 on including concrete types, this is currently a gaping hole in the language. -100 on requiring the concrete type to be first. If I want to specify the types alphabetically, grouped by module, or any other way I choose, why should I not be allowed to do so? The compiler can warn on

[swift-evolution] Subclass Existentials

Hello, As promised, I wrote the first draft of a proposal to add class requirements to the existential syntax. Please let me know what you think. https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/-subclass-existentials.md Regards, David. Existentials for