[swift-evolution] [swift-evolution-announce] [Review] SE-0089: Replace protocol<P1, P2> syntax with Any<P1, P2>

[Matthew Johnson]

> On Jun 7, 2016, at 9:27 PM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
>> 
>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams <dabrahams at apple.com <mailto:dabrahams at apple.com>> wrote:
>> 
>> 
>> on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com <http://matthew-at-anandabits.com/>> wrote:
>> 
>>>> On Jun 7, 2016, at 4:13 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>> on Tue Jun 07 2016, Matthew Johnson <swift-evolution at swift.org <mailto: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.

BTW, Austin’s generalized existentials proposal has several examples of how existential collections would work: https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#protocol-apis-and-associated-types <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md#protocol-apis-and-associated-types>.  

In what ways do you find this functionality insufficient?  What operations do you want to be able to do that this doesn’t support (and can only be supported in an unsafe way that must trap for invalid input)?

> 
> For invalid index because the existential accepts a type erased index?
> 
> How do you decide where to draw the line here?  It feels like a very slippery slope for a language where safety is a stated priority to start adopting a strategy of runtime trapping for something as fundamental as how you expose members on an existential.  
> 
> IMO you should *have* to introduce unsafe behavior like that manually.  Collection indices are already something that isn’t fully statically safe so I understand why you might want to allow this.  But I don’t think having the language's existentials do this automatically is the right approach.  Maybe there is another approach that could be used in targeted use cases where the less safe behavior makes sense and is carefully designed.
> 
>> 
>>> 
>>> 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 <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> -- 
>> Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/c502530e/attachment.html>