We discussed https://github.com/rust-lang/rfcs/issues/1748 in the lang team meeting today. The issue here is that it would be nice to make some “common sense” assumptions about
usize – e.g., that it can be overapproximated with
u64. Of course, this could hinder portability in the future (to 128-bit platforms, if those will ever exist). More generally – and probably more realistically – if one is specifically targetting 16-, 32-, or 64-bit, one might want to be able to interconvert
usize with those types. So what should we do?
Some while back, @aturon started this thread: “A vision for platform architecture / configuration-specific APIs”. This thread didn’t really go anywhere but it suggests a way to handle this scenario. The basic idea is that the libraries and compiler are oriented give you portability “by default” amongst “major” platforms (which we’ll have to define, but I think mac/linux/windows, 32/64-bit is a likely set). If you try to use things that won’t ensure that portability – such as a windows-specific API – you would get lints warning you against that. You can choose to “allow” these lints if that doesn’t bother you.
The interesting part about this is that we can also have lints for portability hazards for lesser-known or more specialized platforms, but those lints default to allow. This means that you can toggle those lints to “deny” if you want to ensure compatibility with those platforms (but, e.g., you may want to re-allow those lints in some parts of your codebase, such as your test code). This basically means that the lints steer you to compatibility with major platforms by default, and other platforms if you choose.
It seems like this approach could well be applied to interconversion between
u64 (or other numeric types). It’s not clear whether we would want to use the
From conversion traits to do said interconversion, though it’s not inconceivable (but we’d have to extend the lints to be able to fire when a particular impl is used).
I will also point out that similar requirements keep coming up in other cases too (e.g., just this week, I brought it up when discussing the composability of unsafe code, but it also applies to embedded use cases). It seems like so long as we want to support a wide, diverse set of platforms and use-cases, there is going to be some amount of divergence where some people want to specialize for their target, but most people want to retain portability amongst “major” systems, without being hassled with supporting every last case.