[swift-evolution] Enhanced existential types proposal discussion

Matthew Johnson matthew at anandabits.com
Fri May 20 09:59:37 CDT 2016



Sent from my iPad

> On May 20, 2016, at 5:18 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> Am 18.05.2016 um 23:17 schrieb Austin Zheng via swift-evolution <swift-evolution at swift.org>:
>> 
>> The order does not affect the semantic meaning of the existential. There is a section in the proposal on how existentials are conceptually 'reduced' from whatever form they take when the programmer types them in, please read it. I am not proposing a macro system. The compiler does not do textual replacement in order to flatten nested existential definitions.
>> 
>> This is also why it makes no sense to have a generic "Any<T, U>", because such a type is identical to "Any<U, T>", which is not true for any other generic type or aggregate type in Swift.
> 
> Shouldn’t that be a reason to use `any<>` (using a keyword `any`) instead of `Any<>`? Because `Any<>` would just look like/be a generic type with all normal expectations, e.g. `Any<T, U>` would *not* be equal to `Any<U, T>` which is different behavior from `protocol<>`, as I can write 
> 
> func foo(p: protocol<A, B>) -> protocol<B, A> {
>     return p
> }
> 

This is a very good point.  +1 to the idea of lowercasing 'any'.

> -Thorsten
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160520/6ee86f33/attachment.html>


More information about the swift-evolution mailing list