Amend RFC 544: Use isize/usize as the literal suffixes for themselves

[CloudiDust]

This RFC (or RFC amendment) proposes that isize/usize get used as the literal suffixes for the types isize/usize, in order to address the problems of the previously chosen is/us.

This RFC used to promote isz/usz, which was brought up by @rkjnsn in this thread.

Rendered View.

Note: the Rendered View shows the amended RFC 544, but the interesting parts are better highlighted in the diff.

[nikomatsakis]

Point of clarification: Can you clarify what the RFC is referring to when it says that "isz" and "usz" would become additional "reserved words"? We're about literal suffixes here, right? That does not require them to be keywords or otherwise reserved, as far as I know.

[rkjnsn]

+1 from me, unsurprisingly.

[tshepang]

I prefer the extremes: usize/isize or i/u suffixes. isz/usz is ugly, but still better than the weird is/us.

[CloudiDust]

@nikomatsakis, I am under this impression because @cmr commented in #544:

(In particular, all literal suffixes are reserved, and whitespace is required around literals to separate them from other tokens)

[CloudiDust]

@tshepang, some would find usize/isize to be too long (myself not included), and i/u may defeat the purpose of the int/uint renaming because i/u feel like the default choices, even though literals without suffixes will fallback to i32/f64, not isize/f64.

[CloudiDust]

@nikomatsakis, and on second thought, i/u used to be valid suffixes and they were not reserved words.

I'll update this PR tonight (local time).

[rkjnsn]

@CloudiDust I took that to mean that all literal suffixes in general are reserved, meaning that it is invalid to put anything other than an existing suffix after a literal, making it possible to add new suffixes later without it being a breaking change.

[CloudiDust]

@rkjnsn, yeah this is also my understanding now. I forgot about i/u.

[rkjnsn]

I'll also note that I'd be fine with isize and usize as suffixes. I don't know if having longer suffixes would be a burden or not. How often are explicitly pointer-sized literals used in everyday code? I don't think I've needed them (the compiler has always been able to infer it), and I've only seen them used in situations where a fixed-size integer would have been better, just because i was so easy to grab at the time.

[winksaville]

+1 for isz/usz

[kennytm]

👍 anything but 0is/0us.

[emberian]

@CloudiDust I didn't mean that suffixes in use needed to be reserved words, merely that all integer suffixes are already reserved.

[liigo]

-1, too ugly

[CloudiDust]

@liigo, then what about isize/usize?

[alfiedotwtf]

+1 to @rkjnsn

We probably want symmetry with the datatype themselves rather than introducing more names.

[1fish2]

To suggest a lightweight empirical approach:

Step 1. Finish converting misuses of isize and usize in the standard library to fixed-size interger types (e.g. in the Int trait).

Step 2. Pick a frequency metric for these literal suffixes, e.g. the % of source files in the library where they appear. Or the % of non-blank, non-comment source lines in the library where they appear. Or the % of integer literals that use these suffixes. Pick high and low bounds, say, 30% and 70% of source files.

Step 3. Grep the library to measure this frequency. If usage is below the low bound, then it's not worth documenting/teaching/remembering/searching/hassling shorthand terms like is or isz just to save a few characters -- use isize/usize for the suffixes. (Tools that read, format, edit, or generate Rust source code will also have to do more to support shorthand terms.) If usage is above the high bound, then Rust programmers will encounter such literals frequently enough to learn and remember the shorthand terms. In between calls for more research and judgement.

Step 4. If shorthand terms may be worth the costs, do a small experiment to see which of 0is/0us, 0isz/0usz, and 0isize/0usize are memorable and understandable. E.g. start a dozen newbies learning Rust via something like The Book extended to introduce the integer types and their literal forms early on, where each third of them would get a variation that uses one of the three proposed literal forms. Then show them a small sample program that contains a usize literal in the form they were taught, and ask them to explain the program. See if they remember the 0us or 0usz or 0usize form.

[liigo]

I did suggest ed isize/usize, in your original int/uint rename RFC, but you
toke is/us then.
2015年1月13日 下午9:58于 "Richard Zhang" notifications@github.com写道：

@liigo https://github.com/liigo, then what about isize/usize?

—
Reply to this email directly or view it on GitHub
#573 (comment).

[CloudiDust]

@1fish2, this can be a fine method if time/resource permits.

@liigo, eh, sorry it seems that you didn't comment about the isize/usize suffix in #544, or have I missed it?

But yes in #544, is/us got chosen. People like @ben0x539, @tshepang, @nstoddard and me argued for isize/usize there. Still a decision needed to be made quickly then and I was not as against is/us as I am now (isize/usize have their own problems), so I didn't argue further.

Now IMHO isz/usz is the best of both worlds, and I will be fine with isize/usize.

[CloudiDust]

Also, is becomes more weird when the optional _ is used:

let answer = 42is; -> let answer = 42_is;

Eh, 42 is what?

While let answer = 42_isz; and let answer = 42_isize; don't have this problem.

[alfiedotwtf]

Just a note - I'm feeling more and more comfortable with is/us as the days go by.

[petrochenkov]

-1
Pure bikeshedding, doesn't worth the effort

[UtherII]

+1 for isz/usz

[archer884]

-1

Not a fan of isz or usz because I hit s and z with the same finger and that's really disruptive. :(

Edit: was looking at some of the other options proposed (when? dunno). Would totally be ok with uz/iz. I know it doesn't necessarily follow as an abbreviation, but I'm used to that (n as abbrev for "decimal," for example).

[phaux]

How about the signed integer becoming just 42sz? I like the sz as an abbreviation of "size", I actually name my variables like that, so +1 for sz in general.

[zonyitoo]

Using is and us may be weird because they are actually two frequently used words in English.
I suggest isize could be shorten as iz and usize as uz.

let val1: iz = 42;
let val2 = 42iz;
let val3: uz = 42;
let val4 = 42uz;

[liigo]

(
just a note, there is no precedent in Rust to have such a abbreviation: 'size' => 'sz'. we usually shorten words by using its prefix(e.g. ref mut impl mod pub) or by using an all-knowing abbr (e.g. fn, a real word).
)

[chrish42]

+1 for "isz" and "usz", because "sz" is a pretty clear abbreviation for "size", so they're clear and succinct in my opinion. But all the other alternatives are better than "is" and "us", in my opinion, which I can't help but read as the verb "is" and the abbreviation for microsecond, like a bunch of other people.

[barosl]

Admitting another bikeshed, iz and uz remind me of the %zu modifier in C's printf. We may call it a precedent.

[tshepang]

If this isn't done by Beta, will we be stuck with is/us 'forever'?

[CloudiDust]

@tshepang, I am not sure.

It seems to me that there are still a fair amount of breaking changes happening, so I'm wondering if the beta should be postponed or if an alpha2 is preferable to a beta1. No matter what the next release is called, if it is going out next week, then I don't expect "non-critical" breaking changes to cease.

[tshepang]

I feel the rush for Alpha (Jan 09) was rather frantic, where people made decisions with not enough discussion/feedback. I'd rather this be avoided in future, so I think next week's release should be another Alpha, not a Beta.

[nrc]

An alternative is to support type ascription, then just use type ascription where necessary and get rid of numeric suffixes.

[CloudiDust]

@nick29581, yeah I just read that RFC and I prefer that now. Let's get rid of the suffixes.

[CloudiDust]

Funny that I was just thinking about making a comment here to suggest type ascription and Nick beat me to it. :)

[CloudiDust]

@tshepang, yeah it should be a new alpha, not a beta. Given that we are considering sweeping changes like the ones in #803 (and its comments), I will be surprised if we get a beta next week.

[aturon]

@tshepang @CloudiDust http://blog.rust-lang.org/2015/02/13/Final-1.0-timeline.html

[nikomatsakis]

Argh, I dropped off this thread for a while. Sorry, lots of demands.

I'd rather not replace suffixes with type ascription. For one thing, there are legitimate concerns raised on the type ascription thread about the desired syntax, and I don't know when it would be unfeature-gated precisely (though I think some form of type ascription is probably inevitable). In any case, it seems like needless backwards incompatibility and pain to remove suffixes.

I've largely been persuaded that we should just use isize and usize as suffixes. Seems most consistent to just use the full type names, and I wouldn't expect this to come up very often. (As for the release schedule, see this recent blog post -- hot off the presses!)

[aturon]

I don't have a strong preference here; isize and usize are OK by me.

[archer884]

As little as it comes up, I'm kinda with everyone else with regard to it
not mattering. Having said that, I did like the ascription thing--if people
more in the know than me can figure out how to make it work?
On Feb 13, 2015 1:37 PM, "Aaron Turon" notifications@github.com wrote:

I don't have a strong preference here; isize and usize are OK by me.

—
Reply to this email directly or view it on GitHub
#573 (comment).

[CloudiDust]

@aturon @nikomatsakis

Thanks for the new timeline and I'll update this RFC to use isize/usize as the primary candidate.

@archer884, I think #803 is a better place for discussions about type ascription. Let's talk there. :)

[tshepang]

\0/

[nikomatsakis]

Just FYI, I started a branch implementing these changes in the background just to observe the effect. So far, all uses of is and us suffixes in the code base have been unnecessary except for one, I think. (Since the stage0 compiler still requires is, but the stage1 compiler requires isize, I changed that case to just do 3 as usize.)

[nikomatsakis]

The branch is here if you are curious: https://github.com/nikomatsakis/rust/tree/suffixes

[CloudiDust]

@nikomatsakis, thanks a lot.

[nikomatsakis]

The core team has decided to accept this RFC. There have been lots of reasonable suggestions, but in the end going with the complete type name seems to be the most unambiguous -- inference ensures that writing out a usize or isize literal is rarely necessary in any case.

[nikomatsakis]

Tracking issue: rust-lang/rust#22496