Implement conversion traits for primitive integer types #28921

petrochenkov · 2015-10-08T23:47:30Z

oli-obk · 2015-10-09T07:02:29Z

src/libcore/num/mod.rs

+impl_from! { u32, usize }
+#[cfg(target_pointer_width = "64")]
+impl_from! { u64, usize }
+#[cfg(target_pointer_width = "16")]


we have support for 16 bit?

No, we don't.

See #27845, https://internals.rust-lang.org/t/adding-16-bit-pointer-support/2484

tbu- · 2015-10-09T08:34:46Z

Very cool. This makes it possible to get rid of lots of as casts for non-truncating casts.

oli-obk · 2015-10-09T08:38:50Z

Very cool. This makes it possible to get rid of lots of as casts for non-truncating casts.

this screams for a lint...

petrochenkov · 2015-10-09T11:27:30Z

@oli-obk

this screams for a lint...

Yes, but not right now, because now we can write large + small as Large, but can't replace it with large + small.into() or large + small.into(): Large yet. Besides, the lint can give platform-dependent warnings (this is solved by cast() in the RFC linked above).

japaric · 2015-10-09T15:00:20Z

but can't replace it with large + small.into() or large + small.into(): Large yet.

But we can write large + Large::from(small) which is one character smaller than the type ascription version 😄.

Nice to see lossless int conversions land in std. I've been using my own From trait that does this + checked casts (return Option), but it would be nice to be able drop that dependency when I only need lossless int casts.

this screams for a lint...

I treat as the same as unsafe (i.e. must be audited) and try to minimize its use in my code; instead, I use lossless/checked usize::froms wherever possible. And, I usually do this by grepping my code for the as keyword because I'm too lazy to (learn how to) write a lint. So, I would very much welcome such a lint. (Then I can copy it and modify it for my needs 😈)

aturon · 2015-10-09T15:58:27Z

src/libcore/num/mod.rs

+impl_from! { u32, u64 }
+#[cfg(any(target_pointer_width = "64", target_pointer_width = "32"))]
+impl_from! { u32, usize }
+#[cfg(target_pointer_width = "64")]


Hmm, I am a bit wary of taking this step: it makes it easy to silently/accidentally introduce arch-specific code. (Contrast this with the approach we took with OS-specific extensions, where you generally have to import a specific trait to "opt in" to platform specificity.)

cc @alexcrichton

It was discussed in the RFC and tested on rustc Windows 64-bit / Linux 32-bit. Yes, porting to a new platform assumes changing some into into cast/as, but potential porting bugs are also uncovered.

Yeah I would prefer to avoid usize and isize in these "always working" coercions for now. I'm not actually aware of any types which have some traits implemented on some platforms and not others, and that's a great boon for portability so it'd be nice to keep it that way!

This is significant and important part of the RFC, it's motivated and tested in practice, I won't surrender it just like that. I'd argue that most of integer conversions actually involve usize.

Any comments from @japaric? Do your own conversion traits perform conversions to/from usize?

Here's some old statistics: https://internals.rust-lang.org/t/the-operator-as-statistics-of-usage/1353
as usize is very popular, including indexing context v[a as usize].

Too bad implemented trait methods can't be marked with a warning message attribute, a lint.
Something like "you use a method making you code non-portable between 32-bit and 64-bit".
If user isn't interested in this kind of portability (or the types are different on different platforms so the conversion is always lossless even if it would not be lossless if the types were the same, but the lint doesn't know that) he could explicitly silence the warning.

Hmm, how do you think, if I write a specialized built-in portability lint for this, would it be a good idea? (This lint could detect other 32<->64 portability problems eventually).

Linting sounds like a reasonable way to approach this problem, for sure; it's an idea that's been tossed around not just for this portability issue, but also to make things like implicit widening part of the language but allow people to "opt out" via a lint.

It'd be awesome if this infrastructure could be used in e.g. the stability lint, which currently is not sensitive to the stability of trait impls. I'm not sure how much work that would be involved.

Okay, so I'm going to comment out the impls problematic for 32<->64 portability for now to merge this PR and will return later with a lint.

@aturon
Done.

aturon · 2015-10-09T16:10:15Z

cc @rust-lang/libs When we discussed this RFC briefly this week, we didn't talk in detail about how usize should be treated. I'd appreciate additional input on this aspect of the design.

tbu- · 2015-10-11T10:10:29Z

With the controversial parts removed, this should be fine to land, right?

aturon · 2015-10-13T14:51:16Z

@tbu- Most likely, though I would like to get broader feedback on the 32bit -> usize conversion. I'm going to flag this for a libs team decision at the meeting tomorrow.

Gankra · 2015-10-13T21:15:23Z

(fwiw we've long held that 16-bit isn't supported. I can't recall any specific past decisions that legitimately preclude it, but I feel like they exist)

alexcrichton · 2015-10-15T01:33:12Z

The libs team talked about this today and our conclusion was that at this time we'd like to avoid any #[cfg] impl blocks entirely. Along those lines we also think that implementations for isize and usize should be avoided at this time. We can always add them later, but it's less obvious that we want to add them right now.

It sounded like one of the main use cases of From and Into with usize/isize were around indexing, but @sfackler brought up a good point where we could certainly implement Index<u64> for vectors and slices today, it's just have extra checks on 32-bit platforms to test if it's out of bounds.

@petrochenkov could you perhaps elaborate a bit on the use cases you're thinking of for isize and usize? Perhaps they can fit into patterns like Index above with slices?

petrochenkov · 2015-10-15T02:29:06Z

@alexcrichton
Updated with completely platform independent version.

could you perhaps elaborate a bit on the use cases you're thinking of for isize and usize?

We can always argue later, but it's less obvious that we want to do it right now

we could certainly implement Index<u64> for vectors and slices

Please, no

alexcrichton · 2015-10-15T03:59:07Z

@bors: r+ 6f3e84d

Thanks!

@aturon

Part of rust-lang/rfcs#1218 (comment) r? @aturon

bors · 2015-10-15T07:11:34Z

⌛ Testing commit 6f3e84d with merge fa9a421...

bors · 2015-10-15T09:04:32Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

briansmith · 2015-10-20T04:18:03Z

@petrochenkov could you perhaps elaborate a bit on the use cases you're thinking of for isize and usize? Perhaps they can fit into patterns like Index above with slices?

I am not @petrochenkov. But, in some cases in my code I have static size values of type u8 or u16 (to keep structures small) that I later need to do usize arithmetic and/or indexing on. Therefore, it would be very useful to have u8 and u16 implicitly convertible to usize.

fwiw we've long held that 16-bit isn't supported

If so, could we please add the u16 -> usize/isize, u32 -> usize, and i32 -> isize conversions that were not added?

briansmith · 2015-10-22T03:07:08Z

If so, could we please add the u16 -> usize/isize, u32 -> usize, and i32 -> isize conversions that were not added?

My PR #29220 adds conversions from u16 to usize, i16 to isize, and u8 to isize. I did not add any conversions from i32 or u32 because there actually is work underway to port Rust to AVR, which uses a 16-bit address space; see https://internals.rust-lang.org/t/adding-16-bit-pointer-support/2484.

briansmith · 2015-10-22T05:22:10Z

we could certainly implement Index for vectors and slices
Please, no

I agree. In particular, that shouldn't be added if it means having a runtime check for 32-bit-and-smaller platforms.

This is a spiritual successor to #28921, completing the "upcast" idea from rust-num/num#97.

rust-highfive assigned aturon Oct 8, 2015

petrochenkov force-pushed the intconv branch from 48b66df to 47f0f2e Compare October 9, 2015 00:08

oli-obk reviewed Oct 9, 2015
View reviewed changes

aturon reviewed Oct 9, 2015
View reviewed changes

petrochenkov force-pushed the intconv branch from 47f0f2e to 5ece8ce Compare October 9, 2015 16:28

petrochenkov mentioned this pull request Oct 13, 2015

Indexed and IndexedMut traits only accept usize #29010

Closed

aturon added I-needs-decision Issue: In need of a decision. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Oct 13, 2015

brson added the relnotes Marks issues that should be documented in the release notes of the next release. label Oct 14, 2015

alexcrichton removed the I-needs-decision Issue: In need of a decision. label Oct 15, 2015

Implement conversion traits for primitive integer types

6f3e84d

petrochenkov force-pushed the intconv branch from f8cac27 to 6f3e84d Compare October 15, 2015 02:24

bors added a commit that referenced this pull request Oct 15, 2015

Auto merge of #28921 - petrochenkov:intconv, r=alexcrichton

fa9a421

Part of rust-lang/rfcs#1218 (comment) r? @aturon

bors merged commit 6f3e84d into rust-lang:master Oct 15, 2015

This was referenced Oct 16, 2015

Trait for Upcasting / Widening rust-num/num#97

Closed

Implement conversion traits for primitive float types #29129

Merged

This was referenced Oct 20, 2015

Remove all casts that use the as operator briansmith/ring#31

Closed

Add additional automatic conversions to usize/isize. #29220

Closed

bors added a commit that referenced this pull request Oct 29, 2015

Auto merge of #29129 - cuviper:impl-from-for-floats, r=alexcrichton

4d11db6

This is a spiritual successor to #28921, completing the "upcast" idea from rust-num/num#97.

petrochenkov deleted the intconv branch November 22, 2015 11:47

petrochenkov mentioned this pull request Dec 20, 2015

the trait core::convert::From<usize> is not implemented for the type u64 #30495

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement conversion traits for primitive integer types #28921

Implement conversion traits for primitive integer types #28921

petrochenkov commented Oct 8, 2015

oli-obk Oct 9, 2015

tbu- Oct 9, 2015

petrochenkov Oct 9, 2015

tbu- commented Oct 9, 2015

oli-obk commented Oct 9, 2015

petrochenkov commented Oct 9, 2015

japaric commented Oct 9, 2015

aturon Oct 9, 2015

petrochenkov Oct 9, 2015

alexcrichton Oct 9, 2015

petrochenkov Oct 9, 2015

petrochenkov Oct 9, 2015

petrochenkov Oct 9, 2015

petrochenkov Oct 9, 2015

aturon Oct 9, 2015

petrochenkov Oct 9, 2015

petrochenkov Oct 9, 2015

aturon commented Oct 9, 2015

tbu- commented Oct 11, 2015

aturon commented Oct 13, 2015

Gankra commented Oct 13, 2015

alexcrichton commented Oct 15, 2015

petrochenkov commented Oct 15, 2015

alexcrichton commented Oct 15, 2015

bors commented Oct 15, 2015

bors commented Oct 15, 2015

briansmith commented Oct 20, 2015

briansmith commented Oct 22, 2015

briansmith commented Oct 22, 2015

Implement conversion traits for primitive integer types #28921

Implement conversion traits for primitive integer types #28921

Conversation

petrochenkov commented Oct 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tbu- commented Oct 9, 2015

oli-obk commented Oct 9, 2015

petrochenkov commented Oct 9, 2015

japaric commented Oct 9, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

aturon commented Oct 9, 2015

tbu- commented Oct 11, 2015

aturon commented Oct 13, 2015

Gankra commented Oct 13, 2015

alexcrichton commented Oct 15, 2015

petrochenkov commented Oct 15, 2015

alexcrichton commented Oct 15, 2015

bors commented Oct 15, 2015

bors commented Oct 15, 2015

briansmith commented Oct 20, 2015

briansmith commented Oct 22, 2015

briansmith commented Oct 22, 2015