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

[Matthew Johnson]

> On Jan 3, 2016, at 8:52 PM, Drew Crawford via swift-evolution <swift-evolution at swift.org> 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 <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html> 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 <swift-evolution at swift.org <mailto:swift-evolution at 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 <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 
>>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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/0000-introducing-interfaces.md <https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>>  _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160103/223d481f/attachment.html>