Updates to the Float API

[brendanzab]

This pull request:

• Merges the Round trait into the Float trait, continuing issue Flatten numeric trait hierarchy and allow for user extensibility. #10387.
• Has floating point functions take their parameters by value.
• Cleans up the formatting and organisation in the definition and implementations of the Float trait.

More information on the breaking changes can be found in the commit messages.

[brendanzab]

r? @brson

[alexcrichton]

If we're moving from &self to self, should Signed and Bitwise also be updated? (in a later PR)

It definitely does lock us in to thinking that the Float trait is only for the primitives, not for fancy wrapper structures (perhaps). (I'm a tad bit hesitant on this part)

[brendanzab]

@alexcrichton It's either that or make everything by-ref for the float trait. It was just confusing because some were by-ref, others were by-val. We have to pick one.

And yes, I'm thinking Signed and Bitwise will be updated too.

cc. @thestinger

[brendanzab]

Oh, and for basic math, 2f64.powf(&100.0) is rather ugly. :(

[brson]

Whether to pick self or &self is a tough decision. The callers look much better here, in what is clearly the much more common case (than custom implementations of Float).

[brson]

Needs rebase.

[brendanzab]

Heading out now - I'll fix this when I get back. I'm ok to r=you @brson?

[thestinger]

I do think it's a lot nicer by-value, but I'm worried that we're heading towards a situation where big integers and arbitrary precision floating point won't fit in to the language at all. It's not going to be possible to define a trait with a method called sqrt that's generic across all floating point types, since it's reserved. It would be nice to have a plan on how this kind of thing is going to be solved in a backwards compatible way.

[brendanzab]

@thestinger: Yeah, that does keep me up at night too... :(

[brendanzab]

@brson rebased

[brson]

@thestinger These methods strike me as the built-in methods for the types - it would be better perhaps if they were just inherent methods. Maybe there can be another set of num traits for generic math.

[bachm]

I much prefer the potentially generic function

hypot(a.x - b.x, a.y - b.y);

over this

(a.x - b.x).hypot(&(a.y - b.y));

[thestinger]

A generic function needs to be written based on a trait method. Either way, a method is required and we've long since decided that we won't be duplication methods with wrapper functions. CTFE will allow methods to be imported/called as functions.

[brendanzab]

@bachm Yeah, I agree that for functions where there is no obvious self parameter, the method call syntax looks weird compared with using a free-function (another example: x.min(y) vs min(x, y)). Apparently the uniform function call syntax changes will allow us to use and import methods like that in the future.

[brendanzab]

@brson maybe we could have free, monomorphic functions in the {f32, f64} modules, then have an optional Float or Ieee754 trait (not exported in the prelude) to provide for a generic API? We could do the same for the integer APIs too.

[thestinger]

I really don't want to go back to having redundant free functions. I don't think backwards compatibility concerns should override good API design when the issues can be solved in other ways.

[brendanzab]

I was considering more the backwards compat question. The free functions would be the implementations, the trait would be a wrapper.

[thestinger]

I would rather just figure out what we need to do to support arbitrary precision arithmetic with the same trait. For example, the return type could be given as a type parameter.

[brendanzab]

Would arbitrary precision arithmetic support the full IEEE though? I would prefer the trait was as close as possible to the spec. (if there are holes, they could be added later)

[brendanzab]

@thestinger could we have:

Float and IeeeFloat: Float?

[brson]

This conversation is going in the direction of redesign. Is this current pull request an improvement we want to make?

@bjz we could also make the free functions fully generic, to reduce duplication, but by value, to make them callable like most expect, leaving the traits to use flexible by-ref calling. Then you just have the fully-generic traits that work with everything, and the free functions that incorrectly consume certain theoretical implementations.

[brendanzab]

we could also make the free functions fully generic, to reduce duplication, but by value, to make them callable like most expect, leaving the traits to use flexible by-ref calling

@brson That's what we had in the past. My eventual goal was to have the free wrapper functions as the main way to call the float methods, and remove Float from the prelude. I think @thestinger and others weren't fans of the duplication though, and removed them in #13225.

[brson]

Another idea: if by-val is bad for some types, then those types can implement Float for &T instead of T.

[brendanzab]

I've thought of this before. You would have to return references, Like: impl<'a> Float for &'a T { fn foo(self) -> &'a T { ... } }