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

[Xiaodi Wu]

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/396afe68/attachment.html>