> Am 08.06.2016 um 20:33 schrieb Dave Abrahams via swift-evolution > <[email protected]>: > > > on Tue Jun 07 2016, Matthew Johnson <matthew-AT-anandabits.com> wrote: > >>> On Jun 7, 2016, at 9:15 PM, Dave Abrahams <[email protected]> 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 >>>>> <[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. >> >> For invalid index because the existential accepts a type erased index? > > Exactly. > >> 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. > > If you don't do this, the alternative is that “Collection where Element > == Int” does not conform to Collection. That's weird and not very > useful. You could expose all the methods that were on protocol > extensions of Collection on this existential, unless they used > associated types other than the element type. But you couldn't pass the > existential to a generic function like > > func scrambled<C: Collection>(_ c: C) -> [C.Element]
I don’t understand. Why couldn’t an existential be passed to that function? -Thorsten > >> IMO you should *have* to introduce unsafe behavior like that manually. > > Collection where Element == Int & Index == * > > ? > >> Collection indices are already something that isn’t fully statically >> safe so I understand why you might want to allow this. > > By the same measure, so are Ints :-) > > The fact that a type's methods have preconditions does *not* make it > “statically unsafe.” > >> 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. > > Whether it makes sense or not really depends on the use-cases. There's > little point in generalizing existentials if the result isn't very useful. > The way to find out is to take a look at the examples we currently have > of protocols with associated types or Self requirements and consider > what you'd be able to do with their existentials if type relationships > couldn't be erased. > > We have known use-cases, currently emulated in the standard library, for > existentials with erased type relationships. *If* these represent the > predominant use cases for something like generalized existentials, it > seems to me that the language feature should support that. Note: I have > not seen anyone build an emulation of the other kind of generalized > existential. My theory: there's a good reason for that :-). > > -- > Dave > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
