On Mon, Jul 18, 2016 at 4:27 PM, Johannes Neubauer <[email protected]> wrote:
> 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. > Swift is a "high-performance system programming language." It claims to be "memory safe by default" and to offer "high-level constructs"; I see no claim that Swift is safe or high-level in other respects. > 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? > I do not. While protocols have semantic meaning, it is up to the owner of a conforming type to ensure that the contract is meaningfully fulfilled. I see no principled reason why Swift should have magic specific for `==` or Equatable and not other methods or protocols. > 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
