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 >> <[email protected]> wrote: >> >> >> on Tue Jun 07 2016, Matthew Johnson <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution -- Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
