<div dir="ltr">It's not possible, even with Swift's current implementation of existentials. A protocol type P isn't considered to conform to itself, thus the following is rejected:<div><br></div><div><div>let a : MyProtocol = // ...</div><div>func myFunc<T : MyProtocol>(x: T) {</div><div> // ....</div><div>}</div><div>myFunc(a) // "Cannot invoke 'myFunc' with an argument list of type MyProtocol"</div></div><div><br></div><div>Changing how this works is probably worth a proposal by itself.</div><div><br></div><div>Austin</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 8, 2016 at 12:34 PM, Thorsten Seitz via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
><br>
><br>
> on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:<br>
><br>
>>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com">dabrahams@apple.com</a>> wrote:<br>
>>><br>
>>><br>
>>> on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com <<a href="http://matthew-at-anandabits.com/" rel="noreferrer" target="_blank">http://matthew-at-anandabits.com/</a>>> wrote:<br>
>>><br>
>><br>
>>>>> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>> on Tue Jun 07 2016, Matthew Johnson <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>>>>><br>
>>>><br>
>>>>>>> , but haven't realized<br>
>>>>>>> that if you step around the type relationships encoded in Self<br>
>>>>>>> requirements and associated types you end up with types that appear to<br>
>>>>>>> interoperate but in fact trap at runtime unless used in exactly the<br>
>>>>>>> right way.<br>
>>>>>><br>
>>>>>> Trap at runtime? How so? Generalized existentials should still be<br>
>>>>>> type-safe.<br>
>>>>><br>
>>>>> There are two choices when you erase static type relationships:<br>
>>>>><br>
>>>>> 1. Acheive type-safety by trapping at runtime<br>
>>>>><br>
>>>>> FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap<br>
>>>>><br>
>>>>> 2. Don't expose protocol requirements that involve these relationships,<br>
>>>>> which would prevent the code above from compiling and prevent<br>
>>>>> FloatingPoint from conforming to itself.<br>
>>>>><br>
>>>>>> Or are you talking about the hypothetical types / behaviors people<br>
>>>>>> think they want when they don’t fully understand what is happening...<br>
>>>>><br>
>>>>> I don't know what you mean here. I think generalized existentials will<br>
>>>>> be nice to have, but I think most people will want them to do something<br>
>>>>> they can't possibly do.<br>
>>>><br>
>>>> Exactly. What I meant is that people think they want that expression<br>
>>>> to compile because they don’t understand that the only thing it can do<br>
>>>> is trap. I said “hypothetical” because producing a compile time error<br>
>>>> rather than a runtime trap is the only sane thing to do. Your comment<br>
>>>> surprised me because I can’t imagine we would move forward in Swift<br>
>>>> with the approach of trapping.<br>
>>><br>
>>> I would very much like to be able to create instances of “Collection<br>
>>> where Element == Int” so we can throw away the wrappers in the stdlib.<br>
>>> That will require some type mismatches to be caught at runtime via<br>
>>> trapping.<br>
>><br>
>> For invalid index because the existential accepts a type erased index?<br>
><br>
> Exactly.<br>
><br>
>> How do you decide where to draw the line here? It feels like a very<br>
>> slippery slope for a language where safety is a stated priority to<br>
>> start adopting a strategy of runtime trapping for something as<br>
>> fundamental as how you expose members on an existential.<br>
><br>
> If you don't do this, the alternative is that “Collection where Element<br>
> == Int” does not conform to Collection. That's weird and not very<br>
> useful. You could expose all the methods that were on protocol<br>
> extensions of Collection on this existential, unless they used<br>
> associated types other than the element type. But you couldn't pass the<br>
> existential to a generic function like<br>
><br>
> func scrambled<C: Collection>(_ c: C) -> [C.Element]<br>
<br>
</div></div>I don’t understand. Why couldn’t an existential be passed to that function?<br>
<br>
-Thorsten<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
>> IMO you should *have* to introduce unsafe behavior like that manually.<br>
><br>
> Collection where Element == Int & Index == *<br>
><br>
> ?<br>
><br>
>> Collection indices are already something that isn’t fully statically<br>
>> safe so I understand why you might want to allow this.<br>
><br>
> By the same measure, so are Ints :-)<br>
><br>
> The fact that a type's methods have preconditions does *not* make it<br>
> “statically unsafe.”<br>
><br>
>> But I don’t think having the language's existentials do this<br>
>> automatically is the right approach. Maybe there is another approach<br>
>> that could be used in targeted use cases where the less safe behavior<br>
>> makes sense and is carefully designed.<br>
><br>
> Whether it makes sense or not really depends on the use-cases. There's<br>
> little point in generalizing existentials if the result isn't very useful.<br>
> The way to find out is to take a look at the examples we currently have<br>
> of protocols with associated types or Self requirements and consider<br>
> what you'd be able to do with their existentials if type relationships<br>
> couldn't be erased.<br>
><br>
> We have known use-cases, currently emulated in the standard library, for<br>
> existentials with erased type relationships. *If* these represent the<br>
> predominant use cases for something like generalized existentials, it<br>
> seems to me that the language feature should support that. Note: I have<br>
> not seen anyone build an emulation of the other kind of generalized<br>
> existential. My theory: there's a good reason for that :-).<br>
><br>
> --<br>
> Dave<br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>