[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