> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution
> <[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
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]
https://lists.swift.org/mailman/listinfo/swift-evolution
