> On Oct 26, 2017, at 2:57 PM, Greg Parker via swift-dev <swift-dev@swift.org>
> wrote:
>
>>
>> On Oct 26, 2017, at 11:47 AM, Xiaodi Wu via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>> On Thu, Oct 26, 2017 at 1:30 PM, Jonathan Hull <jh...@gbis.com
>> <mailto:jh...@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)
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?
- Dave Sweeris
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
