Additive proposals are out of scope for Swift 3; you'll have better luck if you come back around August and propose these one at a time.
I don't see the need for "poor man's existentials" - existential improvements are out of scope for the next release, and there are already a bunch of designs floating around. You might want to search the archives for more details. #3 falls out of a proper implementation of existential types that support protocols with associated types and self requirements. > If the storage implements `Equatable`, this problem should be solved, > right? > > Anyway (punch-line following), although I don’t know how exactly the > low-level Value-Witness-Table works, but if it works as I would expect, > then there should be only exactly one entry per „equal“ storage, and all > collection types with the same data point to the same reference (which is > very memory efficient and table lookup using hashing should be constant > time). If this is correct, a check for `===` suffices. AFAIK, the low-level > swift implementation already checks for `===` on value types that are > stored on the heap (see [this blog post][0]) and don’t bother calling `==` > if `===` holds. > This isn't true. Two buffers can have the same contents and therefore be equal, but be distinct from each other in terms of identity. > > All the best > Johannes > > [0]: > https://www.raywenderlich.com/112029/reference-value-types-in-swift-part-2 > > _______________________________________________ > 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
