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 <[email protected]>: > > 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 <[email protected]> >> wrote: >> Dear Xiaodi, >> >> > Am 18.07.2016 um 20:55 schrieb Xiaodi Wu <[email protected]>: >> > >> > 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 >> > <[email protected]> wrote: >> > >> > > Am 18.07.2016 um 14:01 schrieb Johannes Neubauer via swift-evolution >> > > <[email protected]>: >> > > >> > > >> > >> Am 18.07.2016 um 13:52 schrieb Johannes Neubauer via swift-evolution >> > >> <[email protected]>: >> > >> >> > >>> >> > >>> Am 18.07.2016 um 13:05 schrieb L. Mihalkovic >> > >>> <[email protected]>: >> > >>> >> > >>> 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 >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
