As was mentioned in the Float to int conversions thread. Once there are more rustic versions for the all the primitive conversions that are currently covered by
as it might make sense to remove/deprecate
as. However, I was wondering if it would not be better to move to using
as for calling the
That would be rather disruptive and break a great deal of existing code. It's theoretically possible in an edition, but I'm not sure we'd want to.
It would also break people's mental parsers.
I think that if we were going to do that, it would probably take a whole edition of warning on
as, then another full edition of erroring on
as. So any potential re-use of
as would be 7+ years away, and thus probably not worth discussing in detail at this point.
(That said, I fully support the library having dedicated-purpose versions of all the things that
as can do, such as
wrapping_from or similar.)
The biggest thing i need
as for right now is usize
In indexing, or other places too?
I run into issues with
usize in three places: indexing, creating slices with
[0; some_calculation], and the use of
In the former two cases I need to cast to
usize, and in the third case I need to cast from
I was amused in https://github.com/rust-lang/rust/pull/70835#discussion_r411076438 that it was nicer to use
ctlz(1) (the intrinsic) over
size_of because it meant no casting
Mostly indexing related stuff.
usize mixing is a mess, we need that portability lint system and the "let me tell cargo and rustc i'm assuming that pointers are at least 32 bits" system.
[0; some_calculation] would be even easier to have work with any length than
a[i], I think, since it's a const context.
[0; u128::MAX] isn't any more incorrect than
[0; usize::MAX] already is, so too-big is fine. Something like
[0; my_u8] is of course fine. And even the complaints about signed don't really apply here, since it's a const so you just get a compiler error for
One day it'd be nice if that worked for non-const. But as long as it remains const, yes, anything seems reasonable.
confoundingly, you can't easily make indexing impls for u32 because of how literals seem to work, you get missing trait errors when you write
thing instead of
You can just solve that by also allowing indexing by
i32. Which doesn't even have a speed penalty (for non-ZSTs, but I don't care about slices of ZSTs) compared to indexing by
u32 -- it's just a
sext instead of a
But people seem to hate the thought of indexing by a signed number whenever I bring it up
i think the fix there is to do
signed as unsigned and then redispatch to the unsigned version, then the bounds check will catch it
(you'd get bad panic messages i guess, but whatever)
Right, that's what I mean by just needing to sign-extend, since the limit of
u31::MAX on indexing means you only need one check. (You could still have a different panic message that shows the index as negative, but the checks aren't harder than the unsigned case.)
Wait, why would there be a limit of
sorry, that should have been
isize::MAX, then :D
For PNG specifically, the limit is locked at 31 bits. A PNG's dimensions are positive and not to exceed i32::MAX "because some languages have trouble with unsigned 32-bit values". That's the actual reason written into the spec.