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

[Matthew Johnson via swift-evolution]

> 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 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 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 engineering bandwidth to 
>>> implement it for Swift 3.
>>> 
 Is it something that myself or someone else could work on a formal 
 proposal for?
>>> 
>>> Yes, absolutely. This is a case where I think it’s useful to design what we 
>>> want, even if we cannot fit the implementation into the Swift 3 schedule. 
>>> It’s also a case where the compiler has a lot of the pieces already 
>>> implemented (with some runtime bits landing soon), so the implementation 
>>> should not be *that* hard and will likely not require architectural changes.
>> 
>> Interesting.  I was under the impression the core team was taking on the 
>> generics features. 
> 
> We are, and lots of them. I doubt we can handle another.
> 
>>  I am also very interested in helping to accelerate the process if that is 
>> possible (whether that means Swift 3 or not).
>> 
>> Are you thinking specifically about unbound existentials like in your 
>> Equatable example or also partly / fully bound existentials such as 
>> SequenceType?
> 
> I was thinking mostly about the former. However, the latter is also a 
> highly-requested feature [*] that complements this one, and I think it’s 
> reasonable to discuss both together.
> 
>   - Doug
> 
> [*] And is often the underlying reason why developers ask for parameterized 
> protocols.

Agree.  The other primary motivation I know of for that request is something 
like ConvertibleTo where you multiple conformances would be possible.  

I am familiar with the reasons why Swift is avoiding that path. :)

> 
> 
>> 
>>> 
>>> - Doug
>>> 
 
 -DW
 
> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 
>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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
>>  
>> 
> I am *completely* against this proposal.
> 
> Fundamentally, you're trying to address the limitation that protocols 
> with Self or associated type requirements can't be existential. But it's 
> just a limitation that isn't (conceptually) that hard to fix: the primary 
> operation you need to work with an existing of such a protocol is to 
> "open" a value of existential type, giving a name to the dynamic type it 
> stores. Let's invent one:
> 
>   func eq(x: Equatable, y: Equatable) -> Bool {
> // give the name T to the dynamic type stored in xT
> let xT = open x as T
> // is y also storing a T?
> guard let yT = y as? T else { return false }
> // check whether the Ts are equal
> return xT == yT
>   }
> 
> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
> thing back to something more "static", just by giving a name to the type. 
> Swift generics aren't really even static in any sense: what the do is 
> give names to the types of values so one can establish relationships 
> among different values. "open..as" would do that for existentials. 
> 
> Note that ether Swift compilers AST and SIL both have "open existential" 
> operations that do this internally. They have no spelling in Swift code, 
> but they are useful to describe operations on existentials. At present, 
> they cannot be formed when the existential involves a protocol with Self 
> or associated type requirements, but that's a limitation that isn't hard 
> to address. 
> 
> As for your concerns about knowing when one can dynamically override and 
> when one cannot...  There are issues here that need to be addressed. They 
> aren't significant enough to warrant such a drastic change, and may not 
> even require language changes at all. 
> 
>   - Doug
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/ma

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

[Douglas Gregor via swift-evolution]

> On Jan 4, 2016, at 10:30 AM, Matthew Johnson  wrote:
> 
>> 
>> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> 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 engineering bandwidth to 
>> implement it for Swift 3.
>> 
>>> Is it something that myself or someone else could work on a formal proposal 
>>> for?
>> 
>> Yes, absolutely. This is a case where I think it’s useful to design what we 
>> want, even if we cannot fit the implementation into the Swift 3 schedule. 
>> It’s also a case where the compiler has a lot of the pieces already 
>> implemented (with some runtime bits landing soon), so the implementation 
>> should not be *that* hard and will likely not require architectural changes.
> 
> Interesting.  I was under the impression the core team was taking on the 
> generics features.

We are, and lots of them. I doubt we can handle another.

>  I am also very interested in helping to accelerate the process if that is 
> possible (whether that means Swift 3 or not).
> 
> Are you thinking specifically about unbound existentials like in your 
> Equatable example or also partly / fully bound existentials such as 
> SequenceType?

I was thinking mostly about the former. However, the latter is also a 
highly-requested feature [*] that complements this one, and I think it’s 
reasonable to discuss both together.

- Doug

[*] And is often the underlying reason why developers ask for parameterized 
protocols.


> 
>> 
>>  - Doug
>> 
>>> 
>>> -DW
>>> 
 On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 
> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
> mailto:swift-evolution@swift.org>> wrote:
> 
> 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
>  
> 
 I am *completely* against this proposal.
 
 Fundamentally, you're trying to address the limitation that protocols with 
 Self or associated type requirements can't be existential. But it's just a 
 limitation that isn't (conceptually) that hard to fix: the primary 
 operation you need to work with an existing of such a protocol is to 
 "open" a value of existential type, giving a name to the dynamic type it 
 stores. Let's invent one:
 
   func eq(x: Equatable, y: Equatable) -> Bool {
 // give the name T to the dynamic type stored in xT
 let xT = open x as T
 // is y also storing a T?
 guard let yT = y as? T else { return false }
 // check whether the Ts are equal
 return xT == yT
   }
 
 Ignore the syntax: semantically, we've gone from a "dynamic" existential 
 thing back to something more "static", just by giving a name to the type. 
 Swift generics aren't really even static in any sense: what the do is give 
 names to the types of values so one can establish relationships among 
 different values. "open..as" would do that for existentials. 
 
 Note that ether Swift compilers AST and SIL both have "open existential" 
 operations that do this internally. They have no spelling in Swift code, 
 but they are useful to describe operations on existentials. At present, 
 they cannot be formed when the existential involves a protocol with Self 
 or associated type requirements, but that's a limitation that isn't hard 
 to address. 
 
 As for your concerns about knowing when one can dynamically override and 
 when one cannot...  There are issues here that need to be addressed. They 
 aren't significant enough to warrant such a drastic change, and may not 
 even require language changes at all. 
 
- Doug
 
 
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 https://lists.swift.org/mailman/listinfo/swift-evolution 
 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution 
>  wrote:
> 
> 
>> 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 engineering bandwidth to implement 
> it for Swift 3.
> 
>> Is it something that myself or someone else could work on a formal proposal 
>> for?
> 
> Yes, absolutely. This is a case where I think it’s useful to design what we 
> want, even if we cannot fit the implementation into the Swift 3 schedule. 
> It’s also a case where the compiler has a lot of the pieces already 
> implemented (with some runtime bits landing soon), so the implementation 
> should not be *that* hard and will likely not require architectural changes.

Interesting.  I was under the impression the core team was taking on the 
generics features.  I am also very interested in helping to accelerate the 
process if that is possible (whether that means Swift 3 or not).

Are you thinking specifically about unbound existentials like in your Equatable 
example or also partly / fully bound existentials such as 
SequenceType?

> 
>   - Doug
> 
>> 
>> -DW
>> 
>>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 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
  
 
>>> I am *completely* against this proposal.
>>> 
>>> Fundamentally, you're trying to address the limitation that protocols with 
>>> Self or associated type requirements can't be existential. But it's just a 
>>> limitation that isn't (conceptually) that hard to fix: the primary 
>>> operation you need to work with an existing of such a protocol is to "open" 
>>> a value of existential type, giving a name to the dynamic type it stores. 
>>> Let's invent one:
>>> 
>>>   func eq(x: Equatable, y: Equatable) -> Bool {
>>> // give the name T to the dynamic type stored in xT
>>> let xT = open x as T
>>> // is y also storing a T?
>>> guard let yT = y as? T else { return false }
>>> // check whether the Ts are equal
>>> return xT == yT
>>>   }
>>> 
>>> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
>>> thing back to something more "static", just by giving a name to the type. 
>>> Swift generics aren't really even static in any sense: what the do is give 
>>> names to the types of values so one can establish relationships among 
>>> different values. "open..as" would do that for existentials. 
>>> 
>>> Note that ether Swift compilers AST and SIL both have "open existential" 
>>> operations that do this internally. They have no spelling in Swift code, 
>>> but they are useful to describe operations on existentials. At present, 
>>> they cannot be formed when the existential involves a protocol with Self or 
>>> associated type requirements, but that's a limitation that isn't hard to 
>>> address. 
>>> 
>>> As for your concerns about knowing when one can dynamically override and 
>>> when one cannot...  There are issues here that need to be addressed. They 
>>> aren't significant enough to warrant such a drastic change, and may not 
>>> even require language changes at all. 
>>> 
>>> - Doug
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 engineering bandwidth to implement it 
for Swift 3.

> Is it something that myself or someone else could work on a formal proposal 
> for?

Yes, absolutely. This is a case where I think it’s useful to design what we 
want, even if we cannot fit the implementation into the Swift 3 schedule. It’s 
also a case where the compiler has a lot of the pieces already implemented 
(with some runtime bits landing soon), so the implementation should not be 
*that* hard and will likely not require architectural changes.

- Doug

> 
> -DW
> 
>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 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
>>>  
>>> 
>> I am *completely* against this proposal.
>> 
>> Fundamentally, you're trying to address the limitation that protocols with 
>> Self or associated type requirements can't be existential. But it's just a 
>> limitation that isn't (conceptually) that hard to fix: the primary operation 
>> you need to work with an existing of such a protocol is to "open" a value of 
>> existential type, giving a name to the dynamic type it stores. Let's invent 
>> one:
>> 
>>   func eq(x: Equatable, y: Equatable) -> Bool {
>> // give the name T to the dynamic type stored in xT
>> let xT = open x as T
>> // is y also storing a T?
>> guard let yT = y as? T else { return false }
>> // check whether the Ts are equal
>> return xT == yT
>>   }
>> 
>> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
>> thing back to something more "static", just by giving a name to the type. 
>> Swift generics aren't really even static in any sense: what the do is give 
>> names to the types of values so one can establish relationships among 
>> different values. "open..as" would do that for existentials. 
>> 
>> Note that ether Swift compilers AST and SIL both have "open existential" 
>> operations that do this internally. They have no spelling in Swift code, but 
>> they are useful to describe operations on existentials. At present, they 
>> cannot be formed when the existential involves a protocol with Self or 
>> associated type requirements, but that's a limitation that isn't hard to 
>> address. 
>> 
>> As for your concerns about knowing when one can dynamically override and 
>> when one cannot...  There are issues here that need to be addressed. They 
>> aren't significant enough to warrant such a drastic change, and may not even 
>> require language changes at all. 
>> 
>>  - Doug
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 >> > wrote:
>>> 
 
 On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
> 
> 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: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>>  
>> 
> Thanks.  Joe was basically saying is that associated types would be 
> automatically bound to the existential for their constraints, or Any if 
> there are no constraints.  
> 
> He didn’t specifically mention anything about Self, but I suppose Self 
> requirements could also be automatically bound to Any if the existential 
> type doesn’t specify anything more specific, although I’m not sure I 
> would like that behavior.
> 
> Self is what would apply in the case of:
> 
>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // 
>> error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
> If Self were automatically bound to Any what would this do?  Would it 
> compile and invoke a `<` operator that takes two Any parameters?  That 
> doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you 
> get the correct behavior if first and second were both Int for example.
 
 I gave this some further thought last night and realized what would happen 
 here is pretty clear.  I hadn’t considered existentials where associated 
 types aren’t bound to concrete types before so it just took a few minutes 
 to work through.
 
 Existentials reference a witness table pointing to an actual 
 implementations of the protocol requirements.  Actual implementations 
 require parameters of concrete types.  This means that you must know what 
 that concrete type is and supply a value of that type in order to actually 
 call the member.  The implication of this is that members which require 
 parameters of an associated type that is not bound to a concrete type will 
 not be available on that existential.  
>>> 
>>> There is a concrete type, which is known dynamically to the existential 
>>> value, but you would need a way to name that type to (e.g.) cast down to it 
>>> before you could use the member. That’s why the open..as operation I 
>>> mentioned allows one to use these members: it gives a way to name the type. 
>>> It actually helps to think of any operation on existentials as implicitly 
>>> using open..as, because it makes the semantics far more explicit. (The 
>>> compiler does this internally as well)
>> 
>> Casting down makes sense and of course you could use the member after that.  
>> But why do we need a special cast operation “open” to do this?  Is there a 
>> reason we couldn’t just cast down with the usual operators like we can with 
>> `Any`?
> 
> How are you going to name the type you’re casting to?

Ok, I see now.  I missed that you’re introducing a type variable in the open 
operation.  :)  I mistook T for an arbitrary but concrete type.

> 
>   - Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
 
 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: 
> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>  
> 
 Thanks.  Joe was basically saying is that associated types would be 
 automatically bound to the existential for their constraints, or Any if 
 there are no constraints.  
 
 He didn’t specifically mention anything about Self, but I suppose Self 
 requirements could also be automatically bound to Any if the existential 
 type doesn’t specify anything more specific, although I’m not sure I would 
 like that behavior.
 
 Self is what would apply in the case of:
 
> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // 
> error!
>   if first < second {
> return -1
>   }
>   //...
> }
 If Self were automatically bound to Any what would this do?  Would it 
 compile and invoke a `<` operator that takes two Any parameters?  That 
 doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
 the correct behavior if first and second were both Int for example.
>>> 
>>> I gave this some further thought last night and realized what would happen 
>>> here is pretty clear.  I hadn’t considered existentials where associated 
>>> types aren’t bound to concrete types before so it just took a few minutes 
>>> to work through.
>>> 
>>> Existentials reference a witness table pointing to an actual 
>>> implementations of the protocol requirements.  Actual implementations 
>>> require parameters of concrete types.  This means that you must know what 
>>> that concrete type is and supply a value of that type in order to actually 
>>> call the member.  The implication of this is that members which require 
>>> parameters of an associated type that is not bound to a concrete type will 
>>> not be available on that existential.  
>> 
>> There is a concrete type, which is known dynamically to the existential 
>> value, but you would need a way to name that type to (e.g.) cast down to it 
>> before you could use the member. That’s why the open..as operation I 
>> mentioned allows one to use these members: it gives a way to name the type. 
>> It actually helps to think of any operation on existentials as implicitly 
>> using open..as, because it makes the semantics far more explicit. (The 
>> compiler does this internally as well)
> 
> Casting down makes sense and of course you could use the member after that.  
> But why do we need a special cast operation “open” to do this?  Is there a 
> reason we couldn’t just cast down with the usual operators like we can with 
> `Any`?

How are you going to name the type you’re casting to?

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> On Jan 4, 2016, at 11:43 AM, Douglas Gregor  wrote:
> 
>> 
>> On Jan 4, 2016, at 6:24 AM, Matthew Johnson via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>>> 
>>> 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: 
 https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
  
 
>>> Thanks.  Joe was basically saying is that associated types would be 
>>> automatically bound to the existential for their constraints, or Any if 
>>> there are no constraints.  
>>> 
>>> He didn’t specifically mention anything about Self, but I suppose Self 
>>> requirements could also be automatically bound to Any if the existential 
>>> type doesn’t specify anything more specific, although I’m not sure I would 
>>> like that behavior.
>>> 
>>> Self is what would apply in the case of:
>>> 
 func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // 
 error!
   if first < second {
 return -1
   }
   //...
 }
>>> If Self were automatically bound to Any what would this do?  Would it 
>>> compile and invoke a `<` operator that takes two Any parameters?  That 
>>> doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
>>> the correct behavior if first and second were both Int for example.
>> 
>> I gave this some further thought last night and realized what would happen 
>> here is pretty clear.  I hadn’t considered existentials where associated 
>> types aren’t bound to concrete types before so it just took a few minutes to 
>> work through.
>> 
>> Existentials reference a witness table pointing to an actual implementations 
>> of the protocol requirements.  Actual implementations require parameters of 
>> concrete types.  This means that you must know what that concrete type is 
>> and supply a value of that type in order to actually call the member.  The 
>> implication of this is that members which require parameters of an 
>> associated type that is not bound to a concrete type will not be available 
>> on that existential.  
> 
> There is a concrete type, which is known dynamically to the existential 
> value, but you would need a way to name that type to (e.g.) cast down to it 
> before you could use the member. That’s why the open..as operation I 
> mentioned allows one to use these members: it gives a way to name the type. 
> It actually helps to think of any operation on existentials as implicitly 
> using open..as, because it makes the semantics far more explicit. (The 
> compiler does this internally as well)

Casting down makes sense and of course you could use the member after that.  
But why do we need a special cast operation “open” to do this?  Is there a 
reason we couldn’t just cast down with the usual operators like we can with 
`Any`?

> 
>> In this example, `<` requires two arguments of type Self.  However, the 
>> `Comparable` existential, if allowed, would have Self bound to `Any`, not a 
>> concrete type.  Therefore `<` would not be available and you would receive a 
>> compiler error on that line.  It would be different than the current error 
>> and on a different line of code but it would still fail to compile.
>> 
>> With return types, you do not necessarily need to know the concrete type 
>> returned by the implementation.  Swift could theoretically box the result 
>> itself into an existential and return that to the caller.  I do not know 
>> whether this is the actual design that will be implemented or not.
> 
> It’s a reasonable direction that we’ve discussed in passing but never 
> committed to.
> 
>   - Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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 >> > wrote:
>>> 
>>> Sure, here's the start of the thread: 
>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>>>  
>>> 
>> Thanks.  Joe was basically saying is that associated types would be 
>> automatically bound to the existential for their constraints, or Any if 
>> there are no constraints.  
>> 
>> He didn’t specifically mention anything about Self, but I suppose Self 
>> requirements could also be automatically bound to Any if the existential 
>> type doesn’t specify anything more specific, although I’m not sure I would 
>> like that behavior.
>> 
>> Self is what would apply in the case of:
>> 
>>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>>>   if first < second {
>>> return -1
>>>   }
>>>   //...
>>> }
>> If Self were automatically bound to Any what would this do?  Would it 
>> compile and invoke a `<` operator that takes two Any parameters?  That 
>> doesn’t seem to make sense to me.  It certainly wouldn’t guarantee you get 
>> the correct behavior if first and second were both Int for example.
> 
> I gave this some further thought last night and realized what would happen 
> here is pretty clear.  I hadn’t considered existentials where associated 
> types aren’t bound to concrete types before so it just took a few minutes to 
> work through.
> 
> Existentials reference a witness table pointing to an actual implementations 
> of the protocol requirements.  Actual implementations require parameters of 
> concrete types.  This means that you must know what that concrete type is and 
> supply a value of that type in order to actually call the member.  The 
> implication of this is that members which require parameters of an associated 
> type that is not bound to a concrete type will not be available on that 
> existential.  

There is a concrete type, which is known dynamically to the existential value, 
but you would need a way to name that type to (e.g.) cast down to it before you 
could use the member. That’s why the open..as operation I mentioned allows one 
to use these members: it gives a way to name the type. It actually helps to 
think of any operation on existentials as implicitly using open..as, because it 
makes the semantics far more explicit. (The compiler does this internally as 
well)

> In this example, `<` requires two arguments of type Self.  However, the 
> `Comparable` existential, if allowed, would have Self bound to `Any`, not a 
> concrete type.  Therefore `<` would not be available and you would receive a 
> compiler error on that line.  It would be different than the current error 
> and on a different line of code but it would still fail to compile.
> 
> With return types, you do not necessarily need to know the concrete type 
> returned by the implementation.  Swift could theoretically box the result 
> itself into an existential and return that to the caller.  I do not know 
> whether this is the actual design that will be implemented or not.

It’s a reasonable direction that we’ve discussed in passing but never committed 
to.

- Doug

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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: 
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
>>  
>> 
> Thanks.  Joe was basically saying is that associated types would be 
> automatically bound to the existential for their constraints, or Any if there 
> are no constraints.  
> 
> He didn’t specifically mention anything about Self, but I suppose Self 
> requirements could also be automatically bound to Any if the existential type 
> doesn’t specify anything more specific, although I’m not sure I would like 
> that behavior.
> 
> Self is what would apply in the case of:
> 
>> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
> If Self were automatically bound to Any what would this do?  Would it compile 
> and invoke a `<` operator that takes two Any parameters?  That doesn’t seem 
> to make sense to me.  It certainly wouldn’t guarantee you get the correct 
> behavior if first and second were both Int for example.

I gave this some further thought last night and realized what would happen here 
is pretty clear.  I hadn’t considered existentials where associated types 
aren’t bound to concrete types before so it just took a few minutes to work 
through.

Existentials reference a witness table pointing to an actual implementations of 
the protocol requirements.  Actual implementations require parameters of 
concrete types.  This means that you must know what that concrete type is and 
supply a value of that type in order to actually call the member.  The 
implication of this is that members which require parameters of an associated 
type that is not bound to a concrete type will not be available on that 
existential.  

In this example, `<` requires two arguments of type Self.  However, the 
`Comparable` existential, if allowed, would have Self bound to `Any`, not a 
concrete type.  Therefore `<` would not be available and you would receive a 
compiler error on that line.  It would be different than the current error and 
on a different line of code but it would still fail to compile.

With return types, you do not necessarily need to know the concrete type 
returned by the implementation.  Swift could theoretically box the result 
itself into an existential and return that to the caller.  I do not know 
whether this is the actual design that will be implemented or not.

If I any of the above details are incorrect I hope Joe or someone else will 
correct me.  :)

Matthew

> 
> 
>> 
>> 
>>> On Jan 3, 2016, at 9:10 PM, Matthew Johnson >> > wrote:
>>> 
>>> 
 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 
> associated type in its signature.  So the previous example will always 
> fail to compile. 
 
 Not true.  Joe Groff:
>>> 
>>> Can you point me to the source?  I would like more context around these 
>>> comments.
>>> 
 
> This seems like it would be addressed just by allowing Factory to be used 
> as a dynamic type, with its Product type generalized to Any. We'll be set 
> up to support that with some runtime work to store associated types in 
> protocol witness tables (which is also necessary to fix cyclic 
> conformances, one of our Swift 3 goals).
 
 
> Yeah, when generalizing a protocol type, we ought to be able to either 
> generalize the associated types to their upper bounds, for use cases like 
> yours, or constrain them to specific types, for the AnyGenerator kind 
> of case.
>>> 
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

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 existentials
proposal can be cleaner if properly implemented. Whether the two proposals
are compatible, will be more clear once the syntax for existential types is
established.

Proposal page:
https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Goffredo Marocchi via swift-evolution]

In his message Chris stated that protocols are obviously dynamic while in the 
case of protocol extensions we have default implementations (IMHO out of place 
in protocols if we see protocols are pure abstract contracts designed to 
decouple from the actual implementation) and the compiler will use a static 
implementation just because of the dressing/the type our object is casted as. 
It just feels wrong and an indication that we are now leaking implementation 
details we were trying to hide.

I think this is a compiler optimisation which should not be implicitly applied 
unless it has side effects and this example shows one of those side effects. In 
such cases, I think we should have a keyword to override the compiler with and 
strongly hint we want to enforce the compiler to use the static implementation.

Sent from my iPhone

> On 4 Jan 2016, at 02:52, 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: Comparable, _ second: Comparable) -> Int {  // error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
>> The code above yields an error, and rightfully so, because if the real types 
>> of first and second are not equal, they cannot actually be compared.
>> 
> It is true for Swift 2 code.  However, whether this is true forever is less 
> clear.  There is a thread here discussing "existential protocols", which 
> AFAIK would make this code listing into a non-error, and in that thread 
> Douglas Gregor said:
> 
>> Do recall that I’m saying “not now” rather than “not ever” for this feature. 
>> I think it’s very, very cool, but it’s complicated and we need a while to 
>> understand its overall effects.
> 
> As long as the door is open to allowing the syntax, I think saying something 
> strong and normative about it in an official proposal would be a mistake.  
> The example is fine, but the comment should be that this "currently errors" 
> or "surprises new programmers" or something weaker than "it's obvious to all 
> of us this shouldn't work" because it's obvious to some people that it should 
> work after all.
> 
> The second thing is that I think using the words "dynamically dispatched" or 
> "dynamically dispatched interfaces" in the body of the proposal is a mistake. 
>  It is not that interfaces "are" dynamically dispatched.  It is that they may 
> be, e.g. that the compiler may select a dynamic implementation (or it may be 
> able to find a static implementation), whereas for a protocol the compiler is 
> guaranteed to use a static implementation.  This is I think more consistent 
> with CL's position on static/dynamic in Swift generally.  So I think we 
> should find a turn of phrase like "behaves dynamically" or "has dynamic 
> dispatch semantics" rather than saying "it *is* dynamically dispatched" as if 
> we will force the optimizer to spit out a vtable when it can find a static 
> implementation.
> 
> With those two details resolved I think it is a strong proposal, and very 
> much in line with the proposal we're reviewing about separating typealias vs 
> associatedtype, which strikes at a similar confusion where we're separating 
> two different concepts into their own keywords.
> 
> 
>> On Jan 3, 2016, at 7:44 PM, Austin Zheng via swift-evolution 
>>  wrote:
>> 
>> +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 
>>>  wrote:
>>> 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, 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:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
 
 I am *completely* against this proposal.
 
 Fundamentally, you're trying to address the limitation that protocols with 
 Self or associated type requirements can't be existential. But it's just a 
 limitation that isn't (conceptually) that hard to fix: the primary 
 operation you need to work with an existing of such a protocol is to 
 "open" a value of existential type, giving a name to the dynamic type it 
 stores. Let's invent one:
 
   func eq(x: Equatable, y: Equatable) -> Bool {
 // give the name T to the dynamic ty

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

[Matthew Johnson via swift-evolution]

> 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
>  
> 
Thanks.  Joe was basically saying is that associated types would be 
automatically bound to the existential for their constraints, or Any if there 
are no constraints.  

He didn’t specifically mention anything about Self, but I suppose Self 
requirements could also be automatically bound to Any if the existential type 
doesn’t specify anything more specific, although I’m not sure I would like that 
behavior.

Self is what would apply in the case of:

> func compareTwo(first: Comparable, _ second: Comparable) -> Int {  // error!
>   if first < second {
> return -1
>   }
>   //...
> }
If Self were automatically bound to Any what would this do?  Would it compile 
and invoke a `<` operator that takes two Any parameters?  That doesn’t seem to 
make sense to me.  It certainly wouldn’t guarantee you get the correct behavior 
if first and second were both Int for example.


> 
> 
>> On Jan 3, 2016, at 9:10 PM, Matthew Johnson > > wrote:
>> 
>> 
>>> 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 associated type in 
 its signature.  So the previous example will always fail to compile. 
>>> 
>>> Not true.  Joe Groff:
>> 
>> Can you point me to the source?  I would like more context around these 
>> comments.
>> 
>>> 
 This seems like it would be addressed just by allowing Factory to be used 
 as a dynamic type, with its Product type generalized to Any. We'll be set 
 up to support that with some runtime work to store associated types in 
 protocol witness tables (which is also necessary to fix cyclic 
 conformances, one of our Swift 3 goals).
>>> 
>>> 
 Yeah, when generalizing a protocol type, we ought to be able to either 
 generalize the associated types to their upper bounds, for use cases like 
 yours, or constrain them to specific types, for the AnyGenerator kind 
 of case.
>> 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Drew Crawford via swift-evolution]

Sure, here's the start of the thread: 
https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001856.html
 



> On Jan 3, 2016, at 9:10 PM, Matthew Johnson  wrote:
> 
> 
>> 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 associated type in its 
>>> signature.  So the previous example will always fail to compile. 
>> 
>> Not true.  Joe Groff:
> 
> Can you point me to the source?  I would like more context around these 
> comments.
> 
>> 
>>> This seems like it would be addressed just by allowing Factory to be used 
>>> as a dynamic type, with its Product type generalized to Any. We'll be set 
>>> up to support that with some runtime work to store associated types in 
>>> protocol witness tables (which is also necessary to fix cyclic 
>>> conformances, one of our Swift 3 goals).
>> 
>> 
>>> Yeah, when generalizing a protocol type, we ought to be able to either 
>>> generalize the associated types to their upper bounds, for use cases like 
>>> yours, or constrain them to specific types, for the AnyGenerator kind of 
>>> case.
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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 associated type in its 
>> signature.  So the previous example will always fail to compile. 
> 
> Not true.  Joe Groff:

Can you point me to the source?  I would like more context around these 
comments.

> 
>> This seems like it would be addressed just by allowing Factory to be used as 
>> a dynamic type, with its Product type generalized to Any. We'll be set up to 
>> support that with some runtime work to store associated types in protocol 
>> witness tables (which is also necessary to fix cyclic conformances, one of 
>> our Swift 3 goals).
> 
> 
>> Yeah, when generalizing a protocol type, we ought to be able to either 
>> generalize the associated types to their upper bounds, for use cases like 
>> yours, or constrain them to specific types, for the AnyGenerator kind of 
>> case.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Drew Crawford via swift-evolution]

> 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 compile. 

Not true.  Joe Groff:

> This seems like it would be addressed just by allowing Factory to be used as 
> a dynamic type, with its Product type generalized to Any. We'll be set up to 
> support that with some runtime work to store associated types in protocol 
> witness tables (which is also necessary to fix cyclic conformances, one of 
> our Swift 3 goals).


> Yeah, when generalizing a protocol type, we ought to be able to either 
> generalize the associated types to their upper bounds, for use cases like 
> yours, or constrain them to specific types, for the AnyGenerator kind of 
> case.




___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

> 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: Comparable, _ second: Comparable) -> Int {  // error!
>>   if first < second {
>> return -1
>>   }
>>   //...
>> }
>> The code above yields an error, and rightfully so, because if the real types 
>> of first and second are not equal, they cannot actually be compared.
>> 
> It is true for Swift 2 code.  However, whether this is true forever is less 
> clear.  There is a thread here discussing "existential protocols", which 
> AFAIK would make this code listing into a non-error, and in that thread 
> Douglas Gregor said:
> 
>> Do recall that I’m saying “not now” rather than “not ever” for this feature. 
>> I think it’s very, very cool, but it’s complicated and we need a while to 
>> understand its overall effects.

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 compile. 

> 
> As long as the door is open to allowing the syntax, I think saying something 
> strong and normative about it in an official proposal would be a mistake.  
> The example is fine, but the comment should be that this "currently errors" 
> or "surprises new programmers" or something weaker than "it's obvious to all 
> of us this shouldn't work" because it's obvious to some people that it should 
> work after all.
> 
> The second thing is that I think using the words "dynamically dispatched" or 
> "dynamically dispatched interfaces" in the body of the proposal is a mistake. 
>  It is not that interfaces "are" dynamically dispatched.  It is that they may 
> be, e.g. that the compiler may select a dynamic implementation (or it may be 
> able to find a static implementation), whereas for a protocol the compiler is 
> guaranteed to use a static implementation.  This is I think more consistent 
> with CL's position on static/dynamic in Swift 
> 
>  generally.  So I think we should find a turn of phrase like "behaves 
> dynamically" or "has dynamic dispatch semantics" rather than saying "it *is* 
> dynamically dispatched" as if we will force the optimizer to spit out a 
> vtable when it can find a static implementation.
> 
> With those two details resolved I think it is a strong proposal, and very 
> much in line with the proposal we're reviewing about separating typealias vs 
> associatedtype, which strikes at a similar confusion where we're separating 
> two different concepts into their own keywords.
> 
> 
>> On Jan 3, 2016, at 7:44 PM, Austin Zheng via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> +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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 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 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 
 On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
 mailto:swift-evolution@swift.org>> wrote:
 
 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
  
 
>>> I am *completely* against this proposal.
>>> 
>>> Fundamentally, you're trying to address the limitation that protocols with 
>>> Self or associated type requirements can't be existential. But it's just a 
>>> limitation that isn't (conceptually) that hard to fix: the primary 
>>> operation you need to work with an existing of such a protocol is to "open" 
>>> a value of existential type, giving a name to the dynamic type it stores. 
>>> Let's invent one:
>>> 
>>>   func eq(x: Equatable, y: Equatable) -> Bool {
>>> // give the name T to the dynamic type stored in xT
>>> let xT = open x as T
>>> // is y also storing a T?
>>> guard let yT = y as? T else { return false }
>>> // check whether the Ts are equal
>>> return xT == yT
>>>   }
>>> 
>>> Ignore the syntax: semantically, w

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

[Drew Crawford via swift-evolution]

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
>   }
>   //...
> }
> The code above yields an error, and rightfully so, because if the real types 
> of first and second are not equal, they cannot actually be compared.
> 
It is true for Swift 2 code.  However, whether this is true forever is less 
clear.  There is a thread here discussing "existential protocols", which AFAIK 
would make this code listing into a non-error, and in that thread Douglas 
Gregor said:

> Do recall that I’m saying “not now” rather than “not ever” for this feature. 
> I think it’s very, very cool, but it’s complicated and we need a while to 
> understand its overall effects.

As long as the door is open to allowing the syntax, I think saying something 
strong and normative about it in an official proposal would be a mistake.  The 
example is fine, but the comment should be that this "currently errors" or 
"surprises new programmers" or something weaker than "it's obvious to all of us 
this shouldn't work" because it's obvious to some people that it should work 
after all.

The second thing is that I think using the words "dynamically dispatched" or 
"dynamically dispatched interfaces" in the body of the proposal is a mistake.  
It is not that interfaces "are" dynamically dispatched.  It is that they may 
be, e.g. that the compiler may select a dynamic implementation (or it may be 
able to find a static implementation), whereas for a protocol the compiler is 
guaranteed to use a static implementation.  This is I think more consistent 
with CL's position on static/dynamic in Swift 

 generally.  So I think we should find a turn of phrase like "behaves 
dynamically" or "has dynamic dispatch semantics" rather than saying "it *is* 
dynamically dispatched" as if we will force the optimizer to spit out a vtable 
when it can find a static implementation.

With those two details resolved I think it is a strong proposal, and very much 
in line with the proposal we're reviewing about separating typealias vs 
associatedtype, which strikes at a similar confusion where we're separating two 
different concepts into their own keywords.


> On Jan 3, 2016, at 7:44 PM, Austin Zheng via swift-evolution 
>  wrote:
> 
> +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 
> mailto:swift-evolution@swift.org>> wrote:
> 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 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>>> mailto:swift-evolution@swift.org>> wrote:
>>> 
>>> 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
>>>  
>>> 
>> I am *completely* against this proposal.
>> 
>> Fundamentally, you're trying to address the limitation that protocols with 
>> Self or associated type requirements can't be existential. But it's just a 
>> limitation that isn't (conceptually) that hard to fix: the primary operation 
>> you need to work with an existing of such a protocol is to "open" a value of 
>> existential type, giving a name to the dynamic type it stores. Let's invent 
>> one:
>> 
>>   func eq(x: Equatable, y: Equatable) -> Bool {
>> // give the name T to the dynamic type stored in xT
>> let xT = open x as T
>> // is y also storing a T?
>> guard let yT = y as? T else { return false }
>> // check whether the Ts are equal
>> return xT == yT
>>   }
>> 
>> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
>> thing back to something more "static", just by giving a name to the type. 
>> Swift generics aren't really even static in any sense: what the do is give 
>> names to the types of values so one can establish relationships among 
>> different values. "open..as" would do that for existentials. 
>> 
>> Note that ether Swift compilers AST and SIL both have "open existential" 
>> operations that do this internally. They have no spelling in Swift code, but 
>> they are useful to describe operations on ex

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

[Austin Zheng via swift-evolution]

+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 <
swift-evolution@swift.org> wrote:

> 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 <
> swift-evolution@swift.org> wrote:
>
>
> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution <
> swift-evolution@swift.org> wrote:
>
> 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
>
>
> I am *completely* against this proposal.
>
> Fundamentally, you're trying to address the limitation that protocols with
> Self or associated type requirements can't be existential. But it's just a
> limitation that isn't (conceptually) that hard to fix: the primary
> operation you need to work with an existing of such a protocol is to "open"
> a value of existential type, giving a name to the dynamic type it stores.
> Let's invent one:
>
>   func eq(x: Equatable, y: Equatable) -> Bool {
> // give the name T to the dynamic type stored in xT
> let xT = open x as T
> // is y also storing a T?
> guard let yT = y as? T else { return false }
> // check whether the Ts are equal
> return xT == yT
>   }
>
> Ignore the syntax: semantically, we've gone from a "dynamic" existential
> thing back to something more "static", just by giving a name to the type.
> Swift generics aren't really even static in any sense: what the do is give
> names to the types of values so one can establish relationships among
> different values. "open..as" would do that for existentials.
>
> Note that ether Swift compilers AST and SIL both have "open existential"
> operations that do this internally. They have no spelling in Swift code,
> but they are useful to describe operations on existentials. At present,
> they cannot be formed when the existential involves a protocol with Self or
> associated type requirements, but that's a limitation that isn't hard to
> address.
>
> As for your concerns about knowing when one can dynamically override and
> when one cannot...  There are issues here that need to be addressed. They
> aren't significant enough to warrant such a drastic change, and may not
> even require language changes at all.
>
> - Doug
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

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, 2016, at 6:48 AM, Антон Жилин via swift-evolution 
>> mailto:swift-evolution@swift.org>> wrote:
>> 
>> 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
>>  
>> 
> I am *completely* against this proposal.
> 
> Fundamentally, you're trying to address the limitation that protocols with 
> Self or associated type requirements can't be existential. But it's just a 
> limitation that isn't (conceptually) that hard to fix: the primary operation 
> you need to work with an existing of such a protocol is to "open" a value of 
> existential type, giving a name to the dynamic type it stores. Let's invent 
> one:
> 
>   func eq(x: Equatable, y: Equatable) -> Bool {
> // give the name T to the dynamic type stored in xT
> let xT = open x as T
> // is y also storing a T?
> guard let yT = y as? T else { return false }
> // check whether the Ts are equal
> return xT == yT
>   }
> 
> Ignore the syntax: semantically, we've gone from a "dynamic" existential 
> thing back to something more "static", just by giving a name to the type. 
> Swift generics aren't really even static in any sense: what the do is give 
> names to the types of values so one can establish relationships among 
> different values. "open..as" would do that for existentials. 
> 
> Note that ether Swift compilers AST and SIL both have "open existential" 
> operations that do this internally. They have no spelling in Swift code, but 
> they are useful to describe operations on existentials. At present, they 
> cannot be formed when the existential involves a protocol with Self or 
> associated type requirements, but that's a limitation that isn't hard to 
> address. 
> 
> As for your concerns about knowing when one can dynamically override and when 
> one cannot...  There are issues here that need to be addressed. They aren't 
> significant enough to warrant such a drastic change, and may not even require 
> language changes at all. 
> 
>   - Doug
> 
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Douglas Gregor via swift-evolution]

> 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:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md

I am *completely* against this proposal.

Fundamentally, you're trying to address the limitation that protocols with Self 
or associated type requirements can't be existential. But it's just a 
limitation that isn't (conceptually) that hard to fix: the primary operation 
you need to work with an existing of such a protocol is to "open" a value of 
existential type, giving a name to the dynamic type it stores. Let's invent one:

  func eq(x: Equatable, y: Equatable) -> Bool {
// give the name T to the dynamic type stored in xT
let xT = open x as T
// is y also storing a T?
guard let yT = y as? T else { return false }
// check whether the Ts are equal
return xT == yT
  }

Ignore the syntax: semantically, we've gone from a "dynamic" existential thing 
back to something more "static", just by giving a name to the type. Swift 
generics aren't really even static in any sense: what the do is give names to 
the types of values so one can establish relationships among different values. 
"open..as" would do that for existentials. 

Note that ether Swift compilers AST and SIL both have "open existential" 
operations that do this internally. They have no spelling in Swift code, but 
they are useful to describe operations on existentials. At present, they cannot 
be formed when the existential involves a protocol with Self or associated type 
requirements, but that's a limitation that isn't hard to address. 

As for your concerns about knowing when one can dynamically override and when 
one cannot...  There are issues here that need to be addressed. They aren't 
significant enough to warrant such a drastic change, and may not even require 
language changes at all. 

- Doug


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dave Abrahams via swift-evolution]

> 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 statements seem to be in conflict: existentials create dynamic 
polymorphism, while generics create static polymorphism.

> It is as if "structs" had to be declared as "static class", or "let" 
> variables as "const var". Shorter keywords should be used for enforcing good 
> practices.
> Additionally, 95% of standard library protocols are actually "existential 
> protocols", or "protocols" in my notation.
> 
> Next, I don't know any language which has "existential" keyword. Moreover, 
> "existential types" in Haskell mean means (roughly) "type that can hold value 
> of any instance of class with type erasure", and that is exactly what an 
> interface is in Swift. So, I think that if we will add "existential" keyword, 
> we would add it the other way: for dynamically dispatched types.
> 
> Some other suggestions (imagine a table):
> 
> statically dispatched - dynamically dispatched
> protocol - interface
> protocol - dynamic protocol
> protocol - existential protocol
> static protocol - dynamic protocol
> trait - protocol
> trait - interface
> 
> I also personally like the "trait - protocol" naming. Traits are used to be 
> statically dispatched things in other languages, and protocols are 
> dynamically dispatched things from Objective-C. Actually, I'm satisfied with 
> any pair unless dynamic protocols get shorter names.
> 
> P.S. I'll correct that Self issue, thanks!
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

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. It is as if "structs" had to be
declared as "static class", or "let" variables as "const var". Shorter
keywords should be used for enforcing good practices.
Additionally, 95% of standard library protocols are actually "existential
protocols", or "protocols" in my notation.

Next, I don't know any language which has "existential" keyword. Moreover,
"existential types" in Haskell mean means (roughly) "type that can hold
value of any instance of class with type erasure", and that is exactly what
an interface is in Swift. So, I think that if we will add "existential"
keyword, we would add it the other way: for dynamically dispatched types.

Some other suggestions (imagine a table):

statically dispatched - dynamically dispatched
protocol - interface
protocol - dynamic protocol
protocol - existential protocol
static protocol - dynamic protocol
trait - protocol
trait - interface

I also personally like the "trait - protocol" naming. Traits are used to be
statically dispatched things in other languages, and protocols are
dynamically dispatched things from Objective-C. Actually, I'm satisfied
with any pair unless dynamic protocols get shorter names.

P.S. I'll correct that Self issue, thanks!
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Matthew Johnson via swift-evolution]

Sent from my iPad

> On Jan 3, 2016, at 10:53 AM, David Waite via swift-evolution 
>  wrote:
> 
> 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 in 
> Swift terms.
> 
> Some discussion on this list makes me think that you might instead have a 
> modifier for declaring statically dispatched, existential protocols - e.g. 
> “existential protocol SequenceType { … }”

The problem with *requiring* distinct syntax for protocols that are intended to 
be used as existential a is that it is a stated goal to expand the kinds of 
protocols which can be used as existentials.  In other words, the set of 
protocols that can be used as existentials is a moving target that is likely to 
grow substantially in the future.

I would be comfortable with some kind of optional assertion that a protocol can 
be used as an existential but probably not comfortable with anything more than 
that.

> 
> Also, note not all usage of Self need be disallowed in dynamically 
> dispatch-able types today:
> 
> protocol Test { 
>  func foo() -> Self 
> }
> 
> var t:Test? // legal, I assume on purpose due to the covariance of the return 
> type
> 
> -DW
> 
>> On Jan 3, 2016, at 7: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:
>> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>>  ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[David Waite via swift-evolution]

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 in Swift 
terms.

Some discussion on this list makes me think that you might instead have a 
modifier for declaring statically dispatched, existential protocols - e.g. 
“existential protocol SequenceType { … }”

Also, note not all usage of Self need be disallowed in dynamically 
dispatch-able types today:

protocol Test { 
 func foo() -> Self 
}

var t:Test? // legal, I assume on purpose due to the covariance of the return 
type

-DW

> On Jan 3, 2016, at 7: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:
> https://github.com/Anton3/swift-evolution/blob/master/proposals/-introducing-interfaces.md
>  
> 
>  ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Антон Жилин via swift-evolution]

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution