Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 12:40 PM, Douglas Gregor wrote: > >> >> On Jan 4, 2016, at 10:30 AM, Matthew Johnson > > wrote: >> >>> >>> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution >>>

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

Cleared up that interfaces can be used in static dispatch as well. Added other possible keyword variants instead of protocol/interface (there may still be more). Added some lines about interoperation with existentials proposal. I agree that current proposal is in opposition of it, and that

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 10:44 PM, Matthew Johnson wrote: > > >> On Jan 3, 2016, at 9:14 PM, Drew Crawford > > wrote: >> >> Sure, here's the start of the thread: >>

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution > wrote: > >> >> On Jan 3, 2016, at 10:44 PM, Matthew Johnson > > wrote: >> >> >>> On Jan 3, 2016, at 9:14 PM, Drew Crawford

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 11:43 AM, Douglas Gregor wrote: > >> >> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution >> > wrote: >> >>> >>> On Jan 3, 2016, at 10:44 PM, Matthew Johnson

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 11:56 AM, Douglas Gregor wrote: > >> >> On Jan 4, 2016, at 9:54 AM, Matthew Johnson > > wrote: >> >>> >>> On Jan 4, 2016, at 11:43 AM, Douglas Gregor >>

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 4, 2016, at 9:54 AM, Matthew Johnson wrote: > >> >> On Jan 4, 2016, at 11:43 AM, Douglas Gregor > > wrote: >> >>> >>> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution >>>

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 4:19 PM, David Waite wrote: > > This would be wonderful - is it something that could happen in the Swift 3 > timeframe? I hesitate to say “yes” here. I think it fits with the goals of Swift 3, but my main concern is that there isn’t enough

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

This would be wonderful - is it something that could happen in the Swift 3 timeframe? Is it something that myself or someone else could work on a formal proposal for? -DW > On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution > wrote: > > >> On Jan 3,

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 8:52 PM, Drew Crawford via swift-evolution > wrote: > > I offer a +1, but I have two criticisms of the proposal. > > The first is that the example given in the proposal is stated a lot more > strongly than is true: > >> func compareTwo(first:

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution > wrote: > > Introduction of interfaces will clean up the current blend of static and > dynamic protocols, and solve at least three popular issues. > Please see: >

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 10:25 AM, Антон Жилин via swift-evolution > wrote: > > The problem with syntax of "existential protocol" and "protocol" is that the > first should actually be default, and easier to write. > > We should prefer static to dynamic. These two

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

+1 to "opening" values of existential type, I remember trying (and failing) to do this when Swift 1 came out. Being able to capture the dynamic type of an object at runtime and do stuff with it would be incredible. Austin On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution <

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

I offer a +1, but I have two criticisms of the proposal. The first is that the example given in the proposal is stated a lot more strongly than is true: > func compareTwo(first: Comparable, _ second: Comparable) -> Int { // error! > if first < second { > return -1 > } > //... > } >

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 9:08 PM, Drew Crawford wrote: > >> Existentials for protocols with Self and / or associated type requirements >> would require bindings for Self and / or the associated type(s). At least >> when you use a member that contains Self and / or an

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> Existentials for protocols with Self and / or associated type requirements > would require bindings for Self and / or the associated type(s). At least > when you use a member that contains Self and / or an associated type in its > signature. So the previous example will always fail to

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

> On Jan 3, 2016, at 9:14 PM, Drew Crawford wrote: > > Sure, here's the start of the thread: > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html > >

[swift-evolution] [Proposal] Separate protocols and interfaces

Introduction of interfaces will clean up the current blend of static and dynamic protocols, and solve at least three popular issues. Please see: https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md ___

Re: [swift-evolution] [Proposal] Separate protocols and interfaces

I like this, and had considered proposing something similar. Points: I would have chose to leave protocol to mean the dynamically dispatch-able type declaration, as that is what it indicates in Objective-C. Your proposal would cause every Objective-C protocol to now be considered an interface