> On Jan 3, 2016, at 4:19 PM, David Waite <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> wrote:
>>
>>
>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution
>>> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
