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

[Daniel Resnick]

Forbidding custom `==` for value types would break equality for all Swift
collection types, since they use reference types behind the scenes for
storing memory and copy on write semantics. Furthermore, why should
properties pointing to reference types always use `===`? What if the
reference type conforms to `Equatable`?

On Thu, Jul 14, 2016 at 1:36 PM, Johannes Neubauer via swift-evolution <
swift-evolution at swift.org> wrote:

> Dear Evolutionaries,
>
> First off, I like Swift!
>
> I have some proposals for swift 3ff. (since the `++` operator is
> discouraged ;) ):
>
> 1. Custom implementation of equals operator `==` for value types should be
> forbidden. Rationale: Why has it been added in the first place? For
> omitting some values from the equals test? A user may introduce
> side-effects in that very method, i.e., check some global variable. It
> should to the most be allowed to mark/annotate some properties with
> `transient` or some better name, in order to prevent it being part of the
> equals test. But I would discourage the ability to omit some of the values
> from the equals test, since it does not make sense for value types, does
> it? If a value instance is equal to another, but the value may differ...
> this is odd semantics. Properties pointing at reference types should be
> tested with `===`. The `hashValue` for `Hashable` value types, should be
> auto-computed, too. Since a value type is "kind of" immutable (will be
> copied if it is changed), the hash value can be cached.
> 2. `dispatch` keyword on functions/parameters especially for operators.
> Which leads to dynamic dispatch of one or more parameters (as defined via
> the keyword). Rationale: Swift is a multi-paradigm language. It is neither
> as hard with immutability as Haskell is, but not as open as Python or
> whatever. I see Swift as a golden middle course. This is why in Swift value
> and reference types coexist, isn't it? So, although the focus seems to lie
> on value types and static dispatch, the dynamic world still is your frient,
> right? Adding dynamic/multi dispatch on-demand would be great. Now I have
> to implement it by defining an operator on a super type and implement an
> instance method, which the operator can delegate to. Last but not least, in
> the instance method I have to do the dispatch of the second parameter by
> hand. This feature could be used wonderfully together with value types
> using your great Existential Containers, too.
> 3. As a follow-up to *2.*: `default`-case for methods/operators like
> equals (`==`) to allow safe polymorphic calls for mixed types (or even
> complete pattern matching for method overloading, like many functional
> languages do it for having functions with different entry points for
> different values). Rationale: If you could add a `default`-case (e.g. as an
> additional statement to the `return` or beneath the definition of the
> return type in the method head) which returns `false`, then you could
> safely implement all `T == T` checks and all `T == U` checks will just
> return false. This does not make sense for all methods, but I can imagine
> of more than just equals ;) . This way swift could soften the requirement
> of PATs (Protocol with Associated Types) with the associated type `Self`.
> This would be a very first step to existentials... leading to the next and
> last proposal for today
> 4. Add poor-mans existentials which allow to access non-PAT methods as
> well as methods with a `default`-case (see *3.*). Rationale: I read the
> [generics manifesto][0] and really liked the part [existentials][1]. In a
> first step I wouldn't do complicated things like chaining existentials, but
> do something similar like in structs with `mutating` functions: You just
> cannot call them on `let` variables (compiler error). The same could be
> done for methods using the associated type in their signature (because of
> the co-/contravariance problem) unless the associated type is `Self` and
> the function has a `default`-clause. By the way I think, that not
> implementing pseudo-existentials (like Java and Kotlin do with their
> wildcards or variance declarations `in`/`out` respectively) and I hope that
> the existentials will come to swift in the future... I was a little bit
> afraid that the "Existentials" section is beneath "Unlikely" and "Potential
> Removals", but since these headings are on the same level, this does not
> mean that implementing existentials in the future are unlikely, does it? I
> have some ideas how they could fit into the language very well, if you like
> to hear them...?
>
> I would really appreciate discussing these 4 proposals :) .
>
> All the best
> Johannes
>
> [0]: https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md
> [1]:
> https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#existentials
>
> --
> Dr. Johannes Neubauer
> E-Mail: neubauer at kingsware.de
> WWW   : http://www.kingsware.de
>
>
> _______________________________________________
> 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/f181e59b/attachment.html>