> On Jan 3, 2016, at 8:52 PM, Drew Crawford via swift-evolution
> <swift-evolution@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@swift.org <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
>> <swift-evolution@swift.org <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
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>
>>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution
>>>> <swift-evolution@swift.org <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/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@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <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
