[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