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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
