[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 5:15 PM, Johannes Neubauer <neubauer at kingsware.de>
wrote:

>
>
> Von meinem iPhone gesendet
>
> Am 18.07.2016 um 23:46 schrieb Xiaodi Wu <xiaodi.wu at gmail.com>:
>
> 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.
>
>
> "Easy to learn", and "safe" are attributes that were part of Swifts
> profile from the very beginning: 2-phase initialization, optionals,
> type-safety, no wild-cards for generics, special associated type Self (used
> for equals  and compare for instance)...
>
> 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.
>
>
> There are a lot of papers and books around in (scientific) literature
> about generics, inheritance (e.g. fragile base class problem), the billion
> dollar mistake `null`, off-by-one, just to mention a few, and Swift
> addresses a lot of these problems already (some better and some not as
> good). I would like to propose an option how we can narrow a problem space
> and you talk about magic and constraining freedom.
>

I use "magic" to mean functionality built into the compiler that cannot be
expressed in Swift itself. Without behaviors, attributes require magic, and
because there is no syntax in Swift that can make every function named `==`
call a function named `===`, that too will require magic. I am not sure why
you are putting words in my mouth; I have never used the word "freedom."


> If you like freedom perhaps a dynamically typed language like Python is
> the weapon to choose for you (no offense). But type systems are for safety
> and static type systems constrain the developer in order to reduce the
> possibility of bugs. There is always a tension between safety and
> expressiveness.
>
> I really did a lot of research in these topics and just would like to
> share my knowledge and experience with the community, I do not want to
> steal anyone any feature or something like that. I would really appreciate
> if we could discuss whether an additional safety net for equality, that can
> be deactivated in rare occasion when the developer insists (like forced
> unwrapping for optionals) is something that the Swift community (and the
> core team) would like to have or not. If not, I will not fight for it,
> because I think we all do not have the time to discuss this to the end of
> all time :).
>
> All the best
> Johannes
>
>
>
>> 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.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160718/cbdb217f/attachment.html>