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
