> On Oct 26, 2017, at 3:16 PM, Matthew Johnson <matt...@anandabits.com> wrote:
>
>>
>> On Oct 26, 2017, at 5:12 PM, David Sweeris via swift-dev
>> <swift-dev@swift.org <mailto:swift-dev@swift.org>> wrote:
>>
>>
>>> On Oct 26, 2017, at 2:57 PM, Greg Parker via swift-dev <swift-dev@swift.org
>>> <mailto: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)
>
> 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.
Oh, right... because we can't say "extension Numeric where Self.== doesn't trap
or anything {}"... got it.
Is that why there's not a default implementation of +=, -=, etc?
- Dave Sweeris
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev