Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract math from Float trait #925

Closed
wants to merge 2 commits into from
Closed

Extract math from Float trait #925

wants to merge 2 commits into from

Conversation

hauleth
Copy link

@hauleth hauleth commented Mar 3, 2015

@Diggsey
Copy link
Contributor

Diggsey commented Mar 3, 2015

A single math trait doesn't make sense: the set of mathematical operations on floats is very different from those on integers, or even decimal or fixed point numbers.

@hauleth
Copy link
Author

hauleth commented Mar 5, 2015

I agree that there should be more traits, but on the other hand we shouldn't go insane with splitting them just for having generic code for any numeric type. It should be carefully evaluated.

@aturon aturon self-assigned this Mar 5, 2015
@aturon
Copy link
Member

aturon commented Mar 5, 2015

It kind of reverse RFC #369, but in my opinion it has been too radical which can be seen as num crate bring most of these traits back. This makes num crate kind of must have for any code related to math.

To be clear, the earlier RFC had this as an explicit goal:

Future-proofing for external numerics packages. The Cargo ecosystem should ultimately provide choices of sophisticated numeric hierarchies, and std::num should not get in the way.

As that RFC discusses, there was a long history of changes to std::num and no consensus about what a solid numeric hierarchy would look like. That doesn't mean there will never be one in std, but like many other areas we are leaving it up to crates.io to develop a good set of candidates.

The role of the current traits is primarily just to provide methods on the primitive numeric types, because they cannot be given inherent methods.

@aturon
Copy link
Member

aturon commented Apr 3, 2015

The float trait has been removed in favor of inherent methods. I'm going to close this RFC, since it no longer applies.

FWIW, generic programming over numeric types is a very important area of focus, but this is why we want to let a design bake in crates.io rather than freezing something suboptimal.

@aturon aturon closed this Apr 3, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants