[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>
Dave Abrahams
dabrahams at apple.com
Tue Jun 7 21:15:21 CDT 2016
on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote:
>> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>
>>
>> on Tue Jun 07 2016, Matthew Johnson <swift-evolution at swift.org> wrote:
>>
>
>>>> , but haven't realized
>>>> that if you step around the type relationships encoded in Self
>>>> requirements and associated types you end up with types that appear to
>>>> interoperate but in fact trap at runtime unless used in exactly the
>>>> right way.
>>>
>>> Trap at runtime? How so? Generalized existentials should still be
>>> type-safe.
>>
>> There are two choices when you erase static type relationships:
>>
>> 1. Acheive type-safety by trapping at runtime
>>
>> FloatingPoint(3.0 as Float) + FloatingPoint(3.0 as Double) // trap
>>
>> 2. Don't expose protocol requirements that involve these relationships,
>> which would prevent the code above from compiling and prevent
>> FloatingPoint from conforming to itself.
>>
>>> Or are you talking about the hypothetical types / behaviors people
>>> think they want when they don’t fully understand what is happening...
>>
>> I don't know what you mean here. I think generalized existentials will
>> be nice to have, but I think most people will want them to do something
>> they can't possibly do.
>
> Exactly. What I meant is that people think they want that expression
> to compile because they don’t understand that the only thing it can do
> is trap. I said “hypothetical” because producing a compile time error
> rather than a runtime trap is the only sane thing to do. Your comment
> surprised me because I can’t imagine we would move forward in Swift
> with the approach of trapping.
I would very much like to be able to create instances of “Collection
where Element == Int” so we can throw away the wrappers in the stdlib.
That will require some type mismatches to be caught at runtime via
trapping.
>
> The low hanging fruit in the “protocols whose existentials conform to
> the protocol” space is simple protocols that can already by
> existentials today (like CustomStringConvertible). I don’t know
> enough about Swift’s implementation to comment on how complex it is
> there, but there aren’t any theoretical problems with making their
> existentials conform.
>
>>
>> --
>> -Dave
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
--
Dave
More information about the swift-evolution
mailing list