Stream: general

Topic: new use for `as`

Sebastian Malton (Apr 23 2020 at 15:27, on Zulip):

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 Into trait.

Josh Triplett (Apr 23 2020 at 17:12, on Zulip):

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.

Josh Triplett (Apr 23 2020 at 17:12, on Zulip):

It would also break people's mental parsers.

scottmcm (Apr 23 2020 at 22:44, on Zulip):

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.)

Lokathor (Apr 23 2020 at 22:55, on Zulip):

The biggest thing i need as for right now is usize

scottmcm (Apr 23 2020 at 23:14, on Zulip):

In indexing, or other places too?

Josh Triplett (Apr 23 2020 at 23:15, on Zulip):

I run into issues with usize in three places: indexing, creating slices with [0; some_calculation], and the use of size_of.

Josh Triplett (Apr 23 2020 at 23:16, on Zulip):

In the former two cases I need to cast to usize, and in the third case I need to cast from usize.

scottmcm (Apr 23 2020 at 23:22, on Zulip):

I was amused in that it was nicer to use ctlz(1) (the intrinsic) over size_of because it meant no casting

Lokathor (Apr 23 2020 at 23:37, on Zulip):

Mostly indexing related stuff. u32 / 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.

scottmcm (Apr 23 2020 at 23:54, on Zulip):

Hmm, [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 [0; -1].

Josh Triplett (Apr 23 2020 at 23:58, on Zulip):

One day it'd be nice if that worked for non-const. But as long as it remains const, yes, anything seems reasonable.

Lokathor (Apr 23 2020 at 23:58, on Zulip):

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[1] instead of thing[1_u32]

scottmcm (Apr 23 2020 at 23:59, on Zulip):

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 zext.

scottmcm (Apr 24 2020 at 00:00, on Zulip):

But people seem to hate the thought of indexing by a signed number whenever I bring it up

Lokathor (Apr 24 2020 at 01:10, on Zulip):

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

Lokathor (Apr 24 2020 at 01:10, on Zulip):

(you'd get bad panic messages i guess, but whatever)

scottmcm (Apr 24 2020 at 10:19, on Zulip):

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.)

Josh Triplett (Apr 24 2020 at 19:02, on Zulip):

Wait, why would there be a limit of u31::MAX?

scottmcm (Apr 25 2020 at 00:04, on Zulip):

sorry, that should have been usize::max/2.

RalfJ (Apr 25 2020 at 09:54, on Zulip):

isize::MAX, then :D

Lokathor (Apr 25 2020 at 20:35, on Zulip):

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.

Last update: May 29 2020 at 17:55UTC