Pull Request Test Coverage Report for Build 15357983492

Details

• 6 of 6 (100.0%) changed or added relevant lines in 1 file are covered.
• 6 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.02%) to 84.609%

Totals
Change from base Build 15356157383:	-0.02%
Covered Lines:	23479
Relevant Lines:	27750

💛 - Coveralls

I'll begrudgingly go along with this, but TBH it seems like it'll make the user's life harder without any real benefit. u8 still has too large a range so panics are still possible unless the caller adds pre-checks. This value is conceptually a length so usize is the most natural unit (and what they'll get if they're computing bytes_to_grind based on the length of a slice to populate, or something).

Users may need to add casts where there previously weren't any (e.g. in const contexts) which increases the likelihood of bugs.

This is also a gratuitous breaking change, though it is likely to be low-impact since this is an obscure function usually called with hardcoded constants.

And it doesn't even help #4584 because u8 can't be produced from u32 any easier than usize could.

I'll begrudgingly go along with this, but TBH it seems like it'll make the user's life harder without any real benefit. u8 still has too large a range so panics are still possible unless the caller adds pre-checks. This value is conceptually a length so usize is the most natural unit (and what they'll get if they're computing bytes_to_grind based on the length of a slice to populate, or something).

I won't be too put out if this isn't accepted. Although I do like the principle of using datatypes that are the size they need to be, not just a default size. For example, encoded_size_const(value: u64) -> usize really ought to be encoded_size_const(value: u32) -> u8.

OTOH casting from something small to something large should never be dangerous since you don't accidentally truncate data. I think people just get allergic to seeing as in code since it can cause hard to discover bugs.

If this makes some things worse and nothing really better then I rekon we close it.

If this makes some things worse and nothing really better then I rekon we close it.

Maybe @Kixunil could weigh in on this since he was the prime motivator for this change.

OTOH casting from something small to something large should never be dangerous since you don't accidentally truncate data

Unfortunately this doesn't matter. Rust still forces you to do it when you're going to/from usize, presumably because it makes C programmers antsy if a language gets too well-specified, and it's impossible to tell whether a given instance is safe without looking carefully at it.

(u8 is the one exception -- but unfortunately here we're making users go from usize to u8 which actually might truncate.)

My view is that we should generally use the smallest reasonable type. The ideal type is UpTo62 but that seems too much to me. (Well, ranged types would be great.)

I don't think anyone will compute it from a slice, why would they? This parameter can greatly affect the computation time. At best someone might want to get it from the user.

If we want to be super-stable, we can just take a dumb struct with almost no API and change it to type = u8<0..=62> or whatever the syntax will be in case range types get implemented.

I don't think anyone will compute it from a slice, why would they?

Because the parameter represents an estimated size and they may already have a serialized form of (some of) the object that they are estimating the size of.

My view is that we should generally use the smallest reasonable type.

I agree with this. My viewpoint is this makes the casts safe(er) if going from a smaller type to a larger if a cast is ever needed.