Hi Austin, > Am 15.07.2016 um 00:35 schrieb Austin Zheng <[email protected]>: > > 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.
Ok. I didn’t know that proposals can be only for the next release. I will come back later ;). > 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. Yeah, I had a discussion on swift-dev about this, too. There were some misleading blog posts out there. But perhaps it should be that way… could be another proposal, but not for Swift 3. > > [0]: > https://www.raywenderlich.com/112029/reference-value-types-in-swift-part-2 All the best Johannes
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
