[swift-dev] Rationalizing FloatingPoint conformance to Equatable

[Matthew Johnson]

> On Oct 26, 2017, at 5:12 PM, David Sweeris via swift-dev <swift-dev at swift.org> wrote:
> 
> 
>> On Oct 26, 2017, at 2:57 PM, Greg Parker via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>> 
>>> 
>>> On Oct 26, 2017, at 11:47 AM, Xiaodi Wu via swift-dev <swift-dev at swift.org <mailto:swift-dev at swift.org>> wrote:
>>> 
>>> On Thu, Oct 26, 2017 at 1:30 PM, Jonathan Hull <jhull at gbis.com <mailto:jhull at gbis.com>> wrote:
>>> Now you are just being rude. We all want Swift to be awesome… let’s try to keep things civil.
>>> 
>>> Sorry if my reply came across that way! That wasn't at all the intention. I really mean to ask you those questions and am interested in the answers:
>>> 
>>> Unless I misunderstand, you're arguing that your proposal is superior to Rust's design because of a new operator that returns `Bool?` instead of `Bool`; if so, how is it that you haven't reproduced Rust's design problem, only with the additional syntax involved in unwrapping the result?
>>> 
>>> And if, as I understand, your argument is that your design is superior to Rust's *because* it requires unwrapping, then isn't the extent to which people will avoid using the protocol unintentionally also equally and unavoidably the same extent to which it makes Numeric more cumbersome?
>>> 
>>> You said it was impossible, so I gave you a very quick example showing that the current behavior was still possible.  I wasn’t recommending that everyone should only ever use that example for all things.
>>> 
>>> For FloatingPoint, ‘(a &== b) == true’ would mimic the current behavior (bugs and all). It may not hold for all types.
>>> 
>>> No, the question was how it would be possible to have these guarantees hold for `Numeric`, not merely for `FloatingPoint`, as the purpose is to use `Numeric` for generic algorithms. This requires additional semantic guarantees on what you propose to call `&==`.
>> 
>> Would something like this work?
>> 
>> Numeric.== -> Bool 
>> traps on NaN etc.
>> 
>> Numeric.==? -> Bool? 
>> returns nil on NaN etc. You likely don't want this unless you know something about floating-point.
>> 
>> Numeric.&== -> Bool
>> is IEEE equality. You should not use this unless you are a floating-point expert.
>> 
>> The experts can get high performance or sophisticated numeric behavior. The rest of us who naïvely use == get a relatively foolproof floating-point model. (There is no difference among these three operators for fixed-size integers, of course.)
>> 
>> This is analogous to what Swift does with integer overflow. I would further argue the other Numeric operators like + should be extended to the same triple of trap or optional or just-do-it. We already have two of those three operators for integer addition after all.
>> 
>> Numeric.+ -> T
>> traps on FP NaN and integer overflow
>> 
>> Numeric.+? -> T?
>> returns nil on FP NaN and integer overflow
>> 
>> Numeric.&+ -> T
>> performs FP IEEE addition and integer wraparound
> 
> Works for me (although I'd prefer it if we could we stick to one side for the "modifier" symbols -- either "&+" and  "?+", or "+&" and "+?", and likewise for "==" and its variants)

At a glance this looks like a reasonable solution to me as well.

> Should `Numeric` have extensions that define the variants in terms of `==`, so that authors of custom types don't have to think about it if they don't want to?

Probably not.  In this design `==` is allowed to have a precondition while the variants are not.

> 
> - Dave Sweeris
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20171026/91629d05/attachment.html>