Implement conversion traits for usize/isize together with a portability lint

[joshlf]

This PR was closed 3.5 years ago just prior to the development of the portability lint RFC. In light of the portability lint RFC having been accepted, we should be able to resurrect that PR.

This issue tracks that work. I've submitted it to TWiR's CFP.

[joshtriplett]

Some notable considerations and use case here (note: speaking for myself here, not for any team):

• 32-bit systems are common enough that it seems useful to warn (via the portability lint) on code that assumes usize is at least 64-bit. Code that wants to say "this only runs on 64-bit" should need to specify that.
• 16-bit systems are uncommon enough that it seems unhelpful to warn by default about code that assumes usize is at least 32-bit. I would argue that code should need to opt into dealing with the case where usize is 16-bit.
• 128-bit systems are not yet common, but they lie in the future rather than the past, so it seems reasonable to debate whether we should warn by default about assumptions that usize fits in 64-bit. I personally feel that we should not warn about this by default, but that we may wish to change that in the future.

People have expressed the desire for checked .into() conversions between usize and sized integer types such as u32 or u64; in particular, the two most common requests that don't exist are:

• impl From<u32> for usize
• impl From<usize> for u64

In addition, code that explicitly declares that it only works on a 64-bit target should be able to use impl From<u64> for usize.

[c3st7n]

I would be interested in picking this up.

[joshlf]

@joshtriplett IIU the portability lint RFC correctly, non-portable APIs must be linted no matter how rare the exception cases are, so we'd need to lint even, e.g., impl From<u16> for usize.

@c3st7n Looks like nobody else has spoken up so far, so it's all yours!

[joshtriplett]

On Mon, Apr 06, 2020 at 05:00:43PM -0700, Joshua Liebow-Feeser wrote: @joshtriplett IIU the [portability lint RFC](https://github.com/rust-lang/rfcs/blob/master/text/1868-portability-lint.md) correctly, non-portable APIs must be linted no matter how rare the exception cases are, so we'd need to lint even, e.g., `impl From<u16> for usize`.

I'm arguing that that shouldn't necessarily be the case.

[joshlf]

I'm arguing that that shouldn't necessarily be the case.

Pretty sure that'd need another RFC or at least some other kind of official approval process?

[petrochenkov]

@joshlf
https://github.com/rust-lang/rfcs/blob/master/text/1868-portability-lint.md#background-portability-and-the-standard-library

• We identified a set of "mainstream" platforms, consisting of 32- and 64-bit
  machines running Windows, Linux, or macOS. "Portability by default" thus more
  specifically means portability to mainstream platforms.

The intent was to not warn by default on non-portability to rare platforms, #37423 also implemented the "portability to 16-bit targets" lint as allow-by-default.

[joshlf]

Huh TIL. Thanks for clarifying!

[nikomatsakis]

I'm removing the nomination since I think T-lang doesn't have anything else to say, and I don't think @rust-lang/libs has any objections.

@c3st7n, in terms of implementation work, do you know how to get started?

[c3st7n]

@nikomatsakis I thought I did, my plan was to implement a macro like in @petrochenkov's original PR to add the impl from for each usize/uXX combination, with appropriate target_pointer_width cfg values.

Where I am getting stuck/confused is the portability lint parts. I'm not sure if I am fully understanding them, is the best documentation the RFC (if so, this seems a little odd to me and I would expect something concrete in say the rust book or similar). The above thread refer to warning on different platforms and scenarios, but the way I read the portability lint RFC if I annotate a function with #[cfg(any(target_pointer_width = "32", target_pointer_width = "64"))], tried to call that function and then tried to compile on a 16 bit system, I would get an actual error as the function would essentially not exist. I don't follow how you would use this to warn only?

[sfackler]

The portability lint has never been implemented.

[c3st7n]

I think that probably means I would need a fair bit of help to understand this work or for it to be re-assigned. Happy to carry on if someone can give me some pointers.

[petrochenkov]

The portability lint in #37423 was different from what the RFC described.
It didn't consider any #[cfg]s and only warned if the conversion functions from the non-portable impls were used (on best-effort basis).

[c3st7n]

Ok, this is starting to make a lot more sense to me. I completely misunderstood the full scope of the task and thought there were already portability lints that existed but I was just failing to find/understand them. I will do some further reading and make sure I understand the original PR.

[SimonSapin]

PR #71360 proposes an alternative to this without a portability lint, using instead the same pattern as std::os.

[c3st7n]

I haven't even tried working on this by the way because I am assuming from @SimonSapin comment that this will be made redundant.

[nashley]

I haven't even tried working on this by the way because I am assuming from @SimonSapin comment that this will be made redundant.

Looks like that attempt was abandoned: #71360 (comment)