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

Should we add f80? #2263

Closed
3442853561 opened this Issue Dec 25, 2017 · 10 comments

Comments

Projects
None yet
6 participants
@3442853561
Copy link

3442853561 commented Dec 25, 2017

Should we add f80? Even if it is not often used.

@3442853561 3442853561 changed the title Should we add some trait for f80? Should we add f80? Dec 25, 2017

@Centril

This comment has been minimized.

Copy link
Contributor

Centril commented Dec 25, 2017

I think this issue is under-specified, can you please clarify?

@ranma42

This comment has been minimized.

Copy link
Contributor

ranma42 commented Dec 25, 2017

I agree that some more details are definitely needed.
@3442853561 are you looking for a primitive type that is FFI-compatible with long double in C or for higher-precision floating point types?

@3442853561

This comment has been minimized.

Copy link
Author

3442853561 commented Dec 26, 2017

@ranma42 Yes, I'm looking for a primitive type which like long double in C

@Centril Centril added the T-lang label Dec 26, 2017

@3442853561

This comment has been minimized.

Copy link
Author

3442853561 commented Dec 26, 2017

We can build it as a crate, however I think it should in stdlib instead of other crate.

@Centril Centril added the T-libs label Dec 26, 2017

@3442853561

This comment has been minimized.

Copy link
Author

3442853561 commented Dec 26, 2017

So, what should we do now? Should we create a crate for the f80 type first, and talk about it should enter the standard library later?

@ranma42

This comment has been minimized.

Copy link
Contributor

ranma42 commented Dec 26, 2017

AFAIU support for a type that is compatible with long double in C would not be possible in an external crate, as it needs to be passed in specific ways across function boundaries (depending on the target ABI).
Moreover, f80 is the x86 version of C long double, but other targets behave in a different way (according to https://en.wikipedia.org/wiki/Long_double on SPARC and HP-UX it means f128).

I believe that the main cause for the lack of support in Rust is that long double is not commonly used across language boundaries and there has been little interest in using higher precision floating point numbers in Rust (except maybe through software support).
Some concrete use cases would probably be the first step towards making this issue into a complete RFC.

@clarfon

This comment has been minimized.

Copy link
Contributor

clarfon commented Feb 9, 2018

@ranma42 Honestly, that to me means that implementing both f80 and f128 could help with implementing a c_longdouble for platforms with IEEE 754 support. Although, that'd also mean implementing f16 for completeness and at that point you really start to wonder if all of this is necessary.

That said, all of these types are rigourously defined, which would technically not rule them out for FFI.

@sfackler

This comment has been minimized.

@Centril

This comment has been minimized.

@Centril Centril closed this May 15, 2018

@gnzlbg

This comment has been minimized.

Copy link
Contributor

gnzlbg commented May 15, 2018

FWIW We have already added architecture-specific types, like the SIMD vector types, to std::arch which is in beta. We could probably expose f80 through std::arch as well on those architectures in which it is available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.