### Author:  [@chrisd](https://internals.rust-lang.org/u/chrisd)
#### Post date: [July 28, 2025, 3:33am UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/12 "2025-07-28T03:33:22Z")
Just skimming the top of the list as sorted by `Dependencies / squared size`, I think these would be good candidates:
| Crate | Notes |
| --- | --- |
| hex | convert bytes to and from hexadecimal. Could be an extension to [#138215](https://github.com/rust-lang/rust/issues/138215) maybe |
| urlencoding & percent-encoding | encode and decode url strings |
| byteorder | convinence methods for encoding and decoding big and little endian |
| fastrand | when you just want some "random" looking numbers and don't care about making them unpredictable (or where being predictable may be wanted) |
| walkdir | recursive iteration of directories; super useful but maybe std would want to pick a subset of this |
| tempfile | create anonymous or named temporary files and clean them up on drop |
Except for the last two, these could be in core. Or at least some subset of them could be.
---
### Author:  [@kpreid](https://internals.rust-lang.org/u/kpreid)
#### Post date: [July 28, 2025, 4:01am UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/13 "2025-07-28T04:01:14Z")
> [@dlight](#):
>
> Maybe there should be another floating point wrapper …
The fact that there are so many plausible variations is exactly why this _shouldn’t_ be in `std` yet. Note that you do not just need to decide what values are prohibited, but what the operations that would produce them will do instead! For example, even `NotNan` [just a few months ago](https://github.com/reem/rust-ordered-float/pull/167) changed some operations from returning `NotNan` but panicking on NaN, to returning `T`. That’s the sort of API design iteration that needs to be _thoroughly_ settled and tested in practice before anything enters `std`.
Many people have many complaints with how IEEE floating point works, but it's not _just_ a few “bugs” that you can “fix” and get a well-behaved type out of. You have to look at whether your new design is internally consistent, and whether it works well in practice.
---
### Author:  [@RalfJung](https://internals.rust-lang.org/u/RalfJung)
#### Post date: [July 28, 2025, 7:17am UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/14 "2025-07-28T07:17:25Z")
> [@djc](#):
>
> In addition to stable\_deref\_trait, perhaps at some point equivalent and/or all of indexmap could also make for good additions to core/alloc?
These don't seem to be very far up your list so I am curious how you reached that conclusion?
---
### Author:  [@kornel](https://internals.rust-lang.org/u/kornel)
#### Post date: [July 28, 2025, 12:27pm UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/15 "2025-07-28T12:27:38Z")
This has been discussed previously in the context of `-ffast-math`.
The problem is that different users want different things from non-IEEE floats. It's not just lack of NaN, but only finite, no subnormals, associative, etc. There are also different possible approaches to dealing with violations — extra checks that prevent invalid values, or allowing invalid values and allowing invalid results, but not UB, or maximizing performance at cost of unsafety.
This ends up requiring lots of configuration knobs, and Rust's type system is not suited for it.
---
### Author:  [@dhm](https://internals.rust-lang.org/u/dhm)
#### Post date: [August 1, 2025, 4:44pm UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/16 "2025-08-01T16:44:48Z")
How is the size measured, btw? Does it take comments and doc comments into account? And unit tests?
---
### Author:  [@felix91gr](https://internals.rust-lang.org/u/felix91gr)
#### Post date: [April 19, 2026, 4:38pm UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/17 "2026-04-19T16:38:03Z")
I wonder why the needs & wants are so heterogeneous.
My guess is that this is in no small part due to how we think of decimal numbers. Unlike for subsets of the integers, where we can clearly delineate the borders of the set at both ends (`::MAX` and `::MIN`), we can't do that for any subset of the rationals (or reals) since the concept itself means that they form a dense set.
(Aside) **Dense** here in practice means that in any subset `S` of `P` (`P` here being e.g. the rationals or the reals), if we have two elements `x, y` in `S` such that `x < y`, the element `z = (x + y) / 2` will be such that `x < z < y`, and `z` will always belong to `P`. And if `S` is finite, this means that this operation will eventually take us out of `S`; much like how one can go outside of the floats just by finding space between two of them.
> **What if floats weren't fixed width...?**
>
> Of course, such a limitation can't be lifted for any fixed-width representation. So I don't think we're ever gonna get "satisfying floats" in that sense.
>
> Much like how [`num-bigint`](https://crates.io/crates/num-bigint) uses dynamic width integers to get past the range limitations of ints, one could imagine a decimal type that dynamically increased the information it contains to be able to represent dense decimal ranges. Surprisingly perhaps, this also would allow us to exactly represent roots, trigonometric functions and even many transcendental numbers (such as Pi and e). This set is called the [Computable Numbers](https://en.wikipedia.org/wiki/Computable_number), which are the closest thing I've found to the intuitions we have about dense numbers in algorithms.
Anyway. Floats are kind of fucked. My guess is that half of this is because they're finite-width, which breaks our intuitions about decimals. The other half, we can probably fix within them, though. Well I hope so anyway x3
---
### Author:  [@kornel](https://internals.rust-lang.org/u/kornel)
#### Post date: [April 19, 2026, 9:34pm UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/18 "2026-04-19T21:34:56Z")
Because there are very different problems that happen to use floats as their solution.
Physics engines (and scientific simulations) typically need to carefully control speed vs precision trade-offs, and sometimes need very very specific ways of calculating expressions, so that objects don't fall through the floor.
Similarly ray tracers must be fast, but also have carefully bounded errors in some calculations, since they deal with values that differ by many orders of magnitude and could suffer from systemic errors that add up.
There's audio processing, where most of the time there's plenty of precision headroom, but performance must be predictable, and subnormal floats can be a gotcha.
There's pixel graphics, where often precision doesn't matter, there's just lots of basic arithmetic that needs to be fast. Compilers being careful about edge cases like NaN or rounding of 52nd bit when blending a couple of 8-bit values is just slowing things down.
There's machine learning, UI, animations, that just need some fractional values. There are microcontrollers that just need to convert a few sensor readings.
---
### Author:  [@scottmcm](https://internals.rust-lang.org/u/scottmcm)
#### Post date: [April 19, 2026, 11:32pm UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/19 "2026-04-19T23:32:26Z")
> [@felix91gr](#):
>
> Surprisingly perhaps, this also would allow us to exactly represent roots, trigonometric functions and even many transcendental numbers (such as Pi and e).
Well yes, if you want a [Computer algebra system - Wikipedia](https://en.wikipedia.org/wiki/Computer_algebra_system) you can use one of those -- or a library implementing such in Rust.
---
### Author:  [@Ddystopia](https://internals.rust-lang.org/u/Ddystopia)
#### Post date: [April 21, 2026, 6:23am UTC](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272/20 "2026-04-21T06:23:38Z")
For zerocopy/bytemuck equivalent in std w have a safe transmute project. Unfortunately, it's moving rather slowly
[Next page](https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272.md?page=2)