> On Jun 8, 2016, at 13:16, Dave Abrahams via swift-evolution
> <[email protected]> wrote:
>
>
> on Wed Jun 08 2016, Thorsten Seitz <[email protected]
> <mailto:[email protected]>> wrote:
>
>> Ah, thanks, I forgot! I still consider this a bug, though (will have
>> to read up again what the reasons are for that behavior).
>
> Yes, but in the case of the issue we're discussing, the choices are:
>
> 1. Omit from the existential's API any protocol requirements that depend
> on Self or associated types, in which case it *can't* conform to
> itself because it doesn't fulfill the requirements.
>
> 2. Erase type relationships and trap at runtime when they don't line up.
>
> Matthew has been arguing against #2, but you can't “fix the bug” without
> it.
#1 has been my preference for a while as well, at least as a starting point.
It's possible we could also "open" the existential when it's only used by one
parameter, i.e. the first would be legal and the second wouldn't:
func foo<X: Hashable>(x: X) { … }
func test(x: Any<Hashable>) {
foo(x) // okay, passes the dynamic type
}
func bar<X: Hashable>(a: X, b: X) { … }
func test(x: Any<Hashable>, y: Any<Hashable>) {
bar(x, y) // illegal because x.dynamicType may be different from y.dynamicType
}
(The check is not as simple as "the generic parameter is only mentioned once",
because of constraints and such. But you get the idea.)
Jordan
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution