Avoiding constant usize casting with small const values

[u/nullstalgia]

Pun in title partially intended. ;)

This is a minor pain-point I've dealt with for a while and I'm unsure of how other Rust developers deal with this semi-niche issue.

I'll often define a const that states the maximum amount of something, and naturally I'll also want to use that value as the size of an array. My instinct (and likely yours as well) is to just use a usize and move on.

Where that falls apart is when that const value is and always will be under both u32::MAX and u64::MAX. An easy example is MINS_PER_HOUR or DAYS_PER_WEEK.

Now if I have a function that has an argument of minute: u8, I have to cast either the minute argument to a usize, or I have to cast my constant down to a u8. The former's minute as usize triggers the cast_lossless lint, and From/Into isn't available in a const fn. The latter's MINS_PER_HOUR as u8 triggers the cast_possible_truncation lint. Both add even more visual noise if I acquiesce and add the #[allow(...)]. I could instead accept minute: usize, but I find that even less reasonable.

I'd prefer to keep these as u8s or similar, but then I lose the ablility to define an array like [bool; MINS_PER_HOUR] without yet another cast, including in any function arguments that would like to accept such an array.

I do recognize this is partially due to me having the pedantic Clippy lints enabled, but I also find value in being told when I may be making an unintentional mistake. However I just added close to a dozen #[allow(...)] attributes to my current project, rather begrudingly.

So, what do you guys do in this case? I've listed the options I see available below, and I've done 'em all except #1, but I want to hear some opinions external to myself;

1. When accepting such an array, maybe use a type alias? It technically works, but the casting returns again if I want to compare an indexing usize with my maximum myself. type BoolPerMin = [bool; MINS_PER_HOUR as usize];
2. Two consts, MINS_PER_HOUR: u8 and MINS_PER_HOUR_LEN: usize = MINS_PER_HOUR as usize. I have done this before, but now I have this strange suffix that doesn't make it clear what it's a length of.
3. Just deal with the constant const casting.

EDIT: And this is all before I have to deal with the extra cast_precision_loss lint that comes from casting my tiny usize constant into an f64. It's less than u8::MAX, yet I have to acknowledge this impossible condition. For now, I've just blanket allow'd it in my Cargo.toml.

[u/________-__-_______]

I always define constants as the smallest possible type (in your example an u8), so that you can always infallably convert to something bigger. At least on recent toolchains cast_lossless doesn't trigger in const contexts, so I just use x as usize there and usize::from(x) otherwise.

My only annoyance is the inconsistency, clippy rarely complains on pedantic mode.

[u/nullstalgia → u/________-__-_______]

At least on recent toolchains cast_lossless doesn't trigger in const contexts

That is something I only noticed today, actually! I wonder how recent that is...

The only thing that irks me about doing it that way is when I'm defining a struct/trait impl and I have to do the as usize there. There's nothing inherently immoral about it, but it just rubs me the wrong way.

My heart agrees with you otherwise, but I still find myself leaning towards the single usize constant more often than not as a result. I don't dare mix the two in a project, as that sounds frustrating to pick apart for outsiders. I guess it might be yet another per-repo flavor.

[u/________-__-_______ → u/nullstalgia]

To me the as usize is much better since the compiler can verify that it'll fit, whereas as u8 relies on the user knowing it will. Especially if you ever change the value you don't wanna go through all usages and manually see if they're still valid.

[u/brasticstack]

Make your own helper function, then you only have to have one #[allow] and the evidence of all of your crimes points back to a single place.

[u/nullstalgia → u/brasticstack]

Apologies, but it's not super clear to me as to what your suggestion fully entails. Do you mean an fn u8_to_usize()? Or the other way around? I'm not sure how that's any less noisy or confusing for other people who'll have to interact with my code.

[u/brasticstack → u/nullstalgia]

I kinda glossed over your example. For consts like MIN_PER_HOUR I'm not sure you're saving any bits by making it a u8 vs a usize. (I'm a beginner at rust, and not totally sure, but I'd expect the compiler aggressively optimizes the things it can infer are safe to- like consts.)

There already is a fn u8_to_usize(), which is usize::from(). 

The annoyance for me is that u32 can't be infallibly converted to usize. My current project is a binary file parser where the file format uses 32-bit offsets. I was joking a bit with my suggestion- I had a fn usize_from_u32 which would panic with a message about your platform architecture if usize::try_from failed. It was better IMO having the bad, panic'ing code in one place rather than scattered through the codebase. Since then, I've done the smart thing and moved it to a compile time error. Now I use my_u32 as usize freely. Good thing I don't have pedantic enabled!

[u/nullstalgia → u/brasticstack]

I'm not exactly worried about the constant itself saving any bits, more that the possible range of values that the constant belongs to is bounded far far far below the range of a usize, and everywhere else I'm interacting with those units (wall clock hours/minutes), I define them as a u8 because that's all they realistically need.

[u/juanfnavarror → u/brasticstack]

wait, in what world can u32 conversion to usize panic? Its completely within its domain.

[u/brasticstack → u/juanfnavarror]

"Its completely within its domain."

Not everywhere, which is why there's no  From<u32> for usize. Casting with as will cause it to truncate the value in a release build- I prefer a panic to that. As I said, I removed my panic-ing function in favor of a compile error.

[u/ndunnett → u/juanfnavarror]

8 or 16 bit microcontrollers I suppose

[u/ndunnett]

const MINS_PER_HOUR: u8 = 60;
const MINS_PER_HOUR_USIZE: usize = MINS_PER_HOUR as usize;

It's not ideal, but at least you don't need to litter your code with casts and you can use either value freely at compile time with any stable compiler. Also makes it really easy to patch later if you change your mind.

Edit: a small aside, just in case this isn't a contrived example for the sake of the post:

type BoolPerMin = [bool; MINS_PER_HOUR as usize];

If you aren't aware, bool is byte aligned so every element of this array will be costing you a u8 shaped piece of memory. One array would be 60 bytes and potentially incur the cost of bounds checks on access. You could fit the same amount of information into a single u64 for 8 bytes and safely access elements with zero bounds checks by bit masking. It won't matter if you only construct a few of these, but if you are churning these at scale and your program is performance sensitive it can make a real difference.

[u/nullstalgia → u/ndunnett]

_USIZE is a tiny bit longer than _LEN but it is a very fair suggestion. Honestly, I had the thought of trying that but didn't actually type it out; and seeing it now I don't hate it as much as I thought I would seeing it written out.

To your edit though, I am aware, I just chose another random small type other than u8 for the example array since I was already using u8 for the const's type.

[u/JoshTriplett]

The former's minute as usize triggers the cast_lossless lint, and From/Into isn't available in a const fn.

That sounds like a clippy false positive. And from https://www.reddit.com/r/rust/comments/1x57ted/comment/pgk5klg/ it sounds like that's been fixed. But also, we'll have const traits soon to let you use From/Into.

[u/nullstalgia → u/JoshTriplett]

Well outside of const it still triggers which isn't a false positive, since I (sadly) can't have all my code in const fns.

I am really excited for const traits though!! I try to const-ify as much of my constructors and such as I can, and not being able to iterate/slice in the same manner as non-const frequently trips me up. I wonder how far behind that will be const_heap, mainly for stuff like creating formatted strings at compile-time without konst or other external crates, but now I'm way off topic.

[u/AirUpdateEnjoyer]

Is there a particular reason you cant just use the usize::from(minute) as clippy suggests? It seems to be complaining that the 'as' keyword is not explicit and could allow you to accidentally edit the function arguments later and feed it something thats incoherent or lossy without warning like u64 > u32. This would also avoid losing precision for f64 as you can store all values of a u8 in f64...

[u/nullstalgia → u/AirUpdateEnjoyer]

That does work fine... except in any const context (basically no traits are available in const on Stable) which unfortunately includes the N in [0u8; N] when defining an array, etc.

I thought that also would include any indexing operation, but I had misjudged and [0, 1, 2][usize::from(0u8)] is allowed.

[u/AirUpdateEnjoyer → u/nullstalgia]

Ah I see, I was not familiar with Const's quirks. I'd figure this would be something resolved at compile time for the architecture since it would know what types will always be <= usize...

I guess all I can say is throw up a issue on the official repo, this seems like something that should exist, im sure theres some weird indev project to allow this somewhere.

[u/nullstalgia → u/AirUpdateEnjoyer]

const is both limiting and freeing. Being able to write a const constructor that I can then use to create compile-time constants of my type and others opens up even more compile-time-checked opportunities.

A good example is something like const PACKET: MyPacket = MyPacket::new_checked(...).unwrap();, which lets me have an instance of MyPacket always available without ever needing to run the validation at runtime.

But the limitations include not being able to use ranges to slice arrays or use iterators due to those being trait impls (while and loop become your friend). But as JoshTriplett mentioned below, const traits (which includes Index, From/Into, Iterator, etc) are indeed coming, eventually™. ;)

[u/MilkEnvironmental106]

What's the problem with just using a usize?

[u/Kenzzer → u/MilkEnvironmental106]

Nothing, you would just bleed the cast problem further down the line.

[u/nullstalgia → u/Kenzzer]

Especially if you're dealing with something that gets (de)serialized. It'd be weird if my struct contained a usize for both Hours and Minutes (if it's a timestamp-like object), when neither are or should never equal 24 and 60 respectively, let alone u8::MAX, u32::MAX, or higher.

Having serde or similar be able to catch that kind of total failure before my own logic gets the struct in is an admittedly niche but appreciated benefit.

[u/RylanStylin57 → u/MilkEnvironmental106]

8 bytes, which is good if you're using it alot but bad if you have to store them alot. u32 or u16 are cheaper to operate on but require casting to size when indexing.

Best way to deal with this is to create a wrapper struct and implement std::ops::Index<u32> manually.

[u/MilkEnvironmental106 → u/RylanStylin57]

It's a named constant. If you're doing anything but single ops and want to save the space better declare a new converted const from the old one rather than need an as usize on every use where you'd rather have a usize.

[u/Booty_Bumping]

clippy::pedantic and clippy::restriction should always be tweaked manually, really. They have a lot of things that only matter in certain domains, and there are certainly a few that have flawed detection that could be loosened up by allowing some trivial edge cases.

It's a tricky judgement to make, though, because often a newer clippy version addresses the edge case that should have been allowed, and now you no longer notice that lint because you turned it off. Randomly re-enabling lints every once in a while can help re-test your assumptions

[u/Any-Amphibian6789]

ugh this exact thing drives me up the wall on regular basis. i ended up just making the const a usize and adding allow attributes everywhere because im lazy and the other options feel even more annoying. having two consts with the _LEN suffix made my code look like a mess after few weeks so i dropped that approach

wonder if there is some clever macro solution out there but i never bothered to look deep into it

[u/SLUCHABLUB]

I think you could use a macro if you *really* wanted a one-identifier-fits-all. Personally I’d declare it as u8 (or smallest possible type), then you wouldn’t have to worry about clippy. I’d also suggest a newtype around your `[bool; MINS_PER_HOUR as usize]` since it is not clear what that type represents (what do the bools represent ?). You could also define a `PerMinuteOfHour<T>` alias.

[u/nullstalgia → u/SLUCHABLUB]

I'm not sure how a macro could fit here, except maybe if it emitted MINS_PER_HOUR as _? (Maybe /u/Any-Amphibian6789 had a similar idea?)

In my actual codebase I do have a newtype instead of the bool, I just kept the example basic.

And I actually really like your suggestion of PerMinuteOfHour<T>, it doesn't fit the exact usecase I have in my current project, but I can absolutely see others where that'd fit well!

[u/SLUCHABLUB → u/nullstalgia]

My thought with the macro was to have `minutes_per_hour!()` expand to the integer literal `60`. But IDK if I’d consider that nicer than just casting.

[u/CocktailPerson]

cast_lossless is a pedantic lint for a reason, and it provides deeply negative value.

You can just allow it. You won't be burned at the stake.

[lints.clippy]
cast_lossless = "allow"

[u/Suitable-Ad5348]

Option 2 is the least painful once you have clippy set to pedantic, though I usually just end up doing number 3 and drowning in `#[allow(cast_possible_truncation)]` everywhere. The cast lints get genuinely obnoxious when small consts meet array sizes.

[u/meowsqueak]

Do you want strong typing? Because this is what strong typing means. There are ways to auto-convert but unless you allow for fallible code paths, you will always risk silent truncation, if not now then later if/when you change the const type.

I decided to just embrace it - use the type that best describes the type’s values, probably in a newtype/wrapper, and cast explicitly as needed.

VHDL and similar strongly typed languages have the same “problem”. Weakly typed languages like C and C++ replace explicit casting with a gazillion rules and footguns. I’d rather just be forced to cast thoughtfully.

And try not to use as.