Non-stable {f,u,i}128

1

Hi everyone,

I’ve noticed that the 128-bit floating and integer types are currently available in nightly Rust. I’d like to use these and have no qualms per se about using nightly Rust. So my question is more about why: Why exactly are these types unstable atm? I’ve checked the tracking issue but there isn’t too much recent information on it there and it’s difficult to figure out which of those comments are out of date (can’t check everyone’s private forks, after all).

What issues specifically are holding the u128, i128 and f128 types back from stability? I’m asking because depending on the answers I might go ahead (or not) and use them in a project for work.

2

I can think of one thing: they were just added. New features must be in at least one full release before they're eligible to be made stable.

2 Likes
3

I see. I figured maybe there were known issues with them, but if they’re likely to work (and unlikely to be significantly altered, even if it’s possible because of the unstable label) then I may as well try them out. Thanks!

BTW, would the tracking issue be a good place to put the eventual experience I’ll have with especially f128 and i128? I’m talking about both good and bad experiences :slight_smile:

4

I think there’s no f128.

1 Like
5

Indeed, you’re correct!

I guess I just assumed it would be there side by side with u/i128.

6

Yes, this is true in general for any unstable feature.

7

Yeah, the RFC was focused on integers. There's no reason that we can't do the same for floats.

8

There are currently a couple of issues. i128 broke several non tier1-platforms with varying degrees, like NVPTX, MSP430 and powerpc.

Also, enums can't have #[repr(u128)] yet.

I'm not sure which of those issues are needed to get fixed before stabilisation, but generally some feature always needs to ship for one full cycle in unstable or something.

Yes, please test them! The more people test a new unstable feature, the better, as then more bugs can be found.

2 Likes
9

It's quite natural to solve some Euler Problems using those 128 bit numbers. I have used the extprim crate in past for that.

10

Here's one:

11

I do not expect performance to become a problem, not for at least the next year or so. Given that this will eventually be fixed I’ll still go ahead and try them out.

12

There can never be unity of hardware support when going beyond the lowest common denominator. Taking this argument to the extreme, is there any reason not to support some larger numbers, e.g. u256 and u512? These could be useful for example to represent hash values and do basic computation such as bitwise XOR.

That some "basic" operations like addition might be slow is rather besides the point; optimisation must to some extent be platform-specific anyway.

I see there is already a crate adding such types externally, though it appears only to support bit-logic operations (bitwise or, and, shift, etc.).

13

@leonardo thanks for your report, its greatly appreciated!

The problem on NVPTX/MSP430 is that compilation of any program fails due to i128 support having been added, not just if you use i128. Before stabilizing we need to find out whether to remove i128 support on those platforms, or whether to provide an "emulated" mode where i128 is compiled just like (u64, u64), or something else.

14

Ah. I was arguing that providing emulation of such types is not a bad thing. [Assuming someone writes the emulation code. It should anyway be omitted from the binary if not used.]

15

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.