> On Oct 26, 2017, at 5:12 PM, David Sweeris via swift-dev > <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. > > - Dave Sweeris > _______________________________________________ > swift-dev mailing list > swift-dev@swift.org > https://lists.swift.org/mailman/listinfo/swift-dev
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
