Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 14, 2017, at 1:24 AM, Slava Pestov via swift-evolution > wrote: > >> 3. When a protocol composition type contains a typealias, the validity of >> the type is determined using the following steps: >> >> Expand the typealias >> Normalize the type by removing

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 14, 2017, at 5:28 AM, David Hart wrote: > > > On 14 Feb 2017, at 10:24, Slava Pestov > wrote: > >> >>> On Feb 12, 2017, at 12:32 PM, David Hart via swift-evolution >>>

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 14, 2017, at 3:57 AM, Slava Pestov via swift-evolution > wrote: > > >> On Feb 14, 2017, at 1:30 AM, Adrian Zubarev > > wrote: >> >> Why can’t we completely ban this? >> >> protocol

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On 14 Feb 2017, at 10:57, Slava Pestov via swift-evolution > wrote: > > >> On Feb 14, 2017, at 1:30 AM, Adrian Zubarev >> wrote: >> >> Why can’t we completely ban this? >> >> protocol A {} >> protocol B {} >> typealias AB = A

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On 14 Feb 2017, at 10:24, Slava Pestov wrote: > > >> On Feb 12, 2017, at 12:32 PM, David Hart via swift-evolution >> wrote: >> >> Hi Matthew, >> >> Your arguments made sense to me. I modified the proposal to choose strategy >> number 3:

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

If I recall correctly before Swift 3 something like protocol C : protocol {} was allowed, but it’s banned now. If I understood your opinion than you’re leaning towards: protocol A {} protocol B {} class Super {} class X : Super typealias AB = A & B typealias SuperA = Super & A class Y

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 14, 2017, at 1:30 AM, Adrian Zubarev > wrote: > > Why can’t we completely ban this? > > protocol A {} > protocol B {} > typealias AB = A & B > > protocol C : AB {} // Allowed, but could be also banned > > protocol D : A & B {} // Error > I didn’t

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

Why can’t we completely ban this? protocol A {} protocol B {} typealias AB = A & B protocol C : AB {} // Allowed, but could be also banned protocol D : A & B {} // Error --  Adrian Zubarev Sent with Airmail Am 14. Februar 2017 um 10:25:43, Slava Pestov via swift-evolution

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 12, 2017, at 12:32 PM, David Hart via swift-evolution > wrote: > > Hi Matthew, > > Your arguments made sense to me. I modified the proposal to choose strategy > number 3: deprecating and removing class over several versions to favour > AnyObject. Mind

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

No, you’re totally right there. The mentioned class keyword is the protocol constraint-keyword such as protocol X : >> class << { … }. Instead we would like to generalize AnyObject --  Adrian Zubarev Sent with Airmail Am 13. Februar 2017 um 17:34:18, Alejandro Martinez via swift-evolution

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

On class vs. AnyObject, probablt a dumb question but maybe worth clarifying, we don't pretend to change it in a class declaration right? like AnyObject A { var } apart from that looking forward for this! On Sun, Feb 12, 2017 at 8:32 PM, David Hart via swift-evolution

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

Hi Matthew, Your arguments made sense to me. I modified the proposal to choose strategy number 3: deprecating and removing class over several versions to favour AnyObject. Mind having another proof read?

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 9, 2017, at 2:44 PM, David Hart wrote: > > > On 9 Feb 2017, at 20:43, Matthew Johnson via swift-evolution > > wrote: > >> >> >> Sent from my iPad >> >> On Feb 9, 2017, at 1:30 PM, Hooman Mehr via

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On 9 Feb 2017, at 20:43, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution >> wrote: >> >> On Feb 9, 2017, at 10:47 AM, Joe Groff via

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

Sent from my iPad > On Feb 9, 2017, at 1:30 PM, Hooman Mehr via swift-evolution > wrote: > > >>> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution >>> wrote: >>> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 9, 2017, at 10:47 AM, Joe Groff via swift-evolution > wrote: >> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution >> > wrote: >> Looks good. Minor comments below: >> The typealias

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 9, 2017, at 4:26 AM, Step Christopher via swift-evolution > wrote: > > Looks good. Minor comments below: > >> let t: P & C // Compiler error: subclass contraint must be in first position > > Typo: contraint should be constraint >> >>

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

Looks good. Minor comments below: > let t: P & C // Compiler error: subclass contraint must be in first position Typo: contraint should be constraint > ... > typealias TA4 = D & P2 > typealias TA5 = E & P2 > > typealias TA5 = TA1 & TA2 > typealias TA5 = class & P1 & class & P2 // Expansion >

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

This looks really good, thank you for your work on this proposal David! I agree with Doug’s suggestion to pick #4 (typealias AnyObject = class) and move the other options to alternatives considered. This seems like the best way to go given Swift’s source compatibility promise and will

Re: [swift-evolution] Class and Subclass Existentials (Round 2)

> On Feb 6, 2017, at 1:18 PM, David Hart wrote: > > Hello mailing-list, > > I rewrote the draft proposal concerning the class and subclass existentials. > Please let me know what you think, especially concerning the class and > AnyObject conundrum. Thanks for working on