[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]

On Mon, Jul 18, 2016 at 4:27 PM, Johannes Neubauer <neubauer at kingsware.de>
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 <xiaodi.wu at gmail.com>:
>
> 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/c3d5db88/attachment.html>