> On Oct 25, 2017, at 5:29 AM, David Zarzycki via swift-dev
> <swift-dev@swift.org> wrote:
>
>
>
>> On Oct 25, 2017, at 02:34, Xiaodi Wu via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>> Please see earlier replies summarizing core team members' persuasive
>> arguments as to why not multiple protocol hierarchies like this.
>
> Hi Xiaodi,
>
> The above line is does it help your argument. Even if a person was motivated
> to search through the entire mailing list archives looking for said
> arguments, they won’t be able to guess which arguments you found to be
> persuasive (and who was sufficiently “core” at the time, no less). Can you
> please provide URLs into the archives? Is that a big ask?
If I'm (now) reading this correctly, he put the argument itself at the end of
his earlier reply to you:
> On Oct 24, 2017, at 7:04 PM, Xiaodi Wu via swift-dev <swift-dev@swift.org>
> wrote:
>
> On Tue, Oct 24, 2017 at 4:28 PM, David Zarzycki <d...@znu.io
> <mailto:d...@znu.io>> wrote:
>
>
>> On Oct 24, 2017, at 14:55, Ben Cohen via swift-dev <swift-dev@swift.org
>> <mailto:swift-dev@swift.org>> wrote:
>>
>> There really is no way to square this circle. Every option is going to have
>> downsides. We have to balance correctness, least surprise/most expected
>> behavior for most people, and consistency. For me, making generic use of
>> Equatable and Comparable stick to the documented conformance generically,
>> while keeping FP-specific uses the way they are, is the least bad option.
>
> Hi Ben,
>
> Out of curiosity, what do you think about breaking Equatable into two
> protocols: Equatable and Substitutable? The former would be defined in terms
> of mathematics, while the latter is simple to define and usable by
> collections, etc. For example, while +0 equals -0, they are not substitutable
> (because 1.0 / +0.0 == +inf BUT 1.0 / -0.0 == -inf). In the case of NaNs,
> substitutability would depend on the NaN payload being the same or not
> (because some later subsystem might interpret the NaN payload).
>
> Finally, and unless I’m missing something, floating-point “substitutability”
> would translate to bitwise equality at the hardware level, which is nice from
> a performance perspective.
>
> As Steve pointed out, floating-point "substitutability" as you define it is
> unlikely to be desired in most contexts; differentiation by NaN payload or by
> decimal value representation is highly unintuitive, and it would be
> intolerable for generic `.contains(.nan)` to sometimes return true and
> sometimes false depending on NaN payload.
>
>
> On the topic of sorting, we could do the same thing, where we break
> Comparable into two protocols: Comparable and Sortable. The former would be
> defined in terms of mathematics, while the latter has no mathematical
> obligation and therefore values like +0 and -0 can be consistently sorted.
> The same goes of NaNs with payloads (they can be sorted). And finally, at the
> hardware level, this should be quite efficient because of how the floating
> point bits are laid out (in that an integer comparison of FP bits should work
> for this Sortable proposal).
>
> Floating point values can certainly be consistently sorted as an sequence of
> bits, but again, it is unlikely that anyone would want such a sort of their
> floating point values.
>
> But as to the topic of splitting protocols, it is essentially the design
> adopted by Rust. During discussion of Ben's original proposal, some core team
> members argued very eloquently against such a design based on what's happened
> in Rust. Namely:
>
> - If Float is not Equatable but instead SomethingOtherThanEquatable (in Rust,
> it's called `PartialEq`), then we will have officially done our job in terms
> of stdlib semantic guarantees. However, in practice, people *want* to write
> generic algorithms that work with both integers and floating point values.
> - Based on the Rust experience, what people will do when they realize that
> Float doesn't conform to Equatable is instead to write generic algorithms
> that operate on SomethingOtherThanEquatable while assuming that integer `==`
> and floating point `==` will work the same way.
> - The result is that you now have two protocols instead of one, but most
> people still use only one--and still use it incorrectly. The existing problem
> has simply been transferred from Equatable to SomethingOtherThanEquatable.
> The new Equatable accomplishes nothing in terms of helping people write
> better code.
I just didn't catch that that was "the" argument the first time I read it.
I guess I don't understand why this is persuasive... Seems to me that even if
every relevant generic function that ever ships has it's parameter conform to
"SomethingOtherThanEquatable" instead of "Equatable", the extra protocol has
done something: it's made the programmer acknowledge, on some level, that they
might not always get a sensical result from comparing two values of that type.
Neither "MostlyEquatable" nor "PartialEq" are particularly scary, so maybe they
aren't the best names... If you had to constrain your generic parameters like
"T: EquatableIfYouAreOKWithBridgesFallingDownAndEveryoneDying" to get the
function to work with floating point types, then it'd probably get your
attention.
Moreover, I'd argue that what I called "MaybeEquatable" and "MaybeComparable",
where all the ops return `Bool?`, is the correct semantics for FP comparisons;
it's just that most (all?) hardware doesn't support anything analogous to
`Optional` (and AFAIK, neither did any programming languages at the time
IEEE-754 was created), so there wasn't a way for the IEEE committee to actually
express that idea.
I don't see another way out of it... IEEE floats have partial ordering/eq --
AFAICT it's inherently incorrect for them to conform to a protocol that, for
all other conforming types, has total ordering/eq semantics. That said, I fully
acknowledge that this is all above my pay grade (also I hadn't realized that
the issue was as settled as it apparently is). If splitting the protocols is a
no-go from the get go, I'll go back to trying to figure out a better way to
handle it without doing that.
- Dave Sweeris
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
