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

[Johannes Neubauer]

I think this discussion goes into the wrong direction. Why are we discussing now how these types are implemented? It was just stating the fact, that the swift compiler does not do nothing and swift is a high-level language. I am a fan of bootstrapping (I implemented some bootstrapping processes by myself). If there is a keyword/annotation "iknowwhatido" then these types can be implemented in swift. Still they are implemented by the core team with caution...

But do you agree with me or not that (1) equality is reflexivity, symmetry, and transitivity, and (2) Swift should support the normal developer in fulfilling this contract and (3) that NaN != NaN is an extremely special case?

Perhaps it would be a good idea to have the possibility to identify these special cases and allow to model them (e.g. special case: sink value).

And for the very confident user the default implementation could be deactivated via keyword/annotation.

Von meinem iPhone gesendet

> Am 18.07.2016 um 22:17 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
> 
> You keep saying that floating point types are "basic internal" types, but part of the purpose of having a FloatingPoint protocol and a separate BinaryFloatingPoint protocol is that you can implement your own decimal type without any compiler magic.
> 
>> On Mon, Jul 18, 2016 at 14:28 Johannes Neubauer <neubauer at kingsware.de> wrote:
>> Dear Xiaodi,
>> 
>> > Am 18.07.2016 um 20:55 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
>> >
>> > As mentioned earlier, NaN != NaN, demonstrating that an Equatable instance that does not always equal itself is not "radical." Plainly, your proposal is unworkable.
>> 
>> 1. this is a basic internal type, so it can have a special behavior, since it is a well-designed data type created by the language designers (since there is no need to bootstrap swift from the first bits this is OK).
>> 2. when I made my proposal I didn’t expect that there is such a hard wish for doing things that for sure do **not** comply to the contract of equality (e.g. in order to work with dictionaries and sets). If you allow to implement something like NaN != NaN in custom code, you allow them to implement equality, that is **not reflexive**.
>> 
>> Swift (AFAIK) has three goals:
>> 
>> 1. simplicity
>> 2. performance
>> 3. safety
>> 
>> Allowing things like NaN != NaN in custom value types **without** even flagging it with a keyword like `iknowthisisdangerousbutiknowwhatido`, is against goal 3.
>> 
>> All the best
>> Johannes
>> >
>> >
>> > On Mon, Jul 18, 2016 at 13:48 Johannes Neubauer via swift-evolution <swift-evolution at swift.org> wrote:
>> >
>> > > Am 18.07.2016 um 14:01 schrieb Johannes Neubauer via swift-evolution <swift-evolution at swift.org>:
>> > >
>> > >
>> > >> Am 18.07.2016 um 13:52 schrieb Johannes Neubauer via swift-evolution <swift-evolution at swift.org>:
>> > >>
>> > >>>
>> > >>> Am 18.07.2016 um 13:05 schrieb L. Mihalkovic <laurent.mihalkovic at gmail.com>:
>> > >>>
>> > >>> IMHO implementing your proposal would close the door on some of the things you do when building in-memory dbs (T == U -> TRUE for T not related to U), which if swift remains for small apps is not a terrible loss, but may be more of an issue for one day doing big-data with it.
>> > >>
>> > >> You talk about reference types now, right? I proposed a `default` keyword, which (in a pattern matching fashion) would catch all calls to T == U for which no implementation exists (so this is exactly when T != U). You could of course change for a given type hierarchy the `default` result to `true` if appropriate.
>> > >
>> > > This formulation can be misleading: I mean `a == b` where `a: T` and `b: U` and `T != U`. Due to dynamic dispatch even: `a.dynamicType == T && b.dynamicType == U && T != U`.
>> >
>> > But I think, for such a radical different semantic than the normal interpretation of equality I think I wouldn’t use the `Equatable`-protocol at all, but implement a custom protocol with a custom operator.
>> > _______________________________________________
>> > 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/20160718/1c7aab50/attachment.html>