[swift-evolution] Proposals: (1) Forbidding custom `==` for value types, (2) `dispatch` keyword, (3) `default`-result for methods with `Self`, and (4) Poor-Mans-Existentials

[Austin Zheng]

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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160714/c19a0610/attachment.html>