> 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

Reply via email to