Two minor wording issues in the Chinese translation of The Book (Ch 3.1 & 3.2)

help
1

Hello everyone,

I'm reading the Chinese translation of The Rust Programming Language ( Rust 程序设计语言 - Rust 程序设计语言 简体中文版 ) and came across two small wording issues that I think could be clarified. I wanted to discuss them here before potentially opening a GitHub issue.

Issue 1: Chapter 3.1 - Variables and Mutability

In the section explaining this compile-time error:

let mut spaces = " ";
spaces = spaces.len();

The book says (translated): "This error shows that we cannot change the type of a variable."

I think this is a bit misleading because Rust does allow changing a variable's type through shadowing (let spaces = spaces.len();). The actual error is a type mismatch — you're trying to assign a usize value to a &str variable.

Wouldn't it be more accurate to say something like: "This error shows that we cannot assign a usize value to a variable of type &str, because their types don't match."?

Issue 2: Chapter 3.2 - Scalar Types (Integer Types)

In the introduction to signed/unsigned integers, the book says (translated): "whether it is always positive, and therefore does not need a sign (unsigned)".

Mathematically, zero is neither positive nor negative. Unsigned integers represent non-negative numbers (zero and positive), not just "positive" numbers. I think this should be corrected to "whether it is always non-negative (zero or positive)" to be mathematically precise.

2

Shadowing does not change type of the variable. It makes a new variable with the same name. If you had in middle let r = &mut spaces; you would be referencing the shadowed variable (and it is not the new variable when using r.)

I can't read the Chinese but here appears to be what you might have translation from;

Each variant can be either signed or unsigned and has an explicit size. Signed and unsigned refer to whether it’s possible for the number to be negative—in other words, whether the number needs to have a sign with it (signed) or whether it will only ever be positive and can therefore be represented without a sign (unsigned). It’s like writing numbers on paper: When the sign matters, a number is shown with a plus sign or a minus sign; however, when it’s safe to assume the number is positive, it’s shown with no sign. Signed numbers are stored using two’s complement representation.

Data Types - The Rust Programming Language

Rust has NonZero. At least in my education integer has included zero and natural-numbers do not.

3

原来不同国家/教材自然数是否包含零还不一样， 但中国这是不包含零的。所以最少中文应该是不严谨的

4

E.g.

#![allow(unused)]

fn main() {
    let mut x = 0u8;
    if true {
        let x = String::from("t");
    } else {
        let x = String::from("f");
    }
    x = 1;
}

The original variable being shadowed didn't destroy or replace it. (Alternative exercise: make some types that print on drop and observe how shadowing doesn't change what drops, or when.)

(OTOH calling the error a type mismatch is accurate. Pretty ambivalent on that one (in English)).

I don't read Chinese, but for the original English I agree that "will only ever be positive" should be "will never be negative" (or something like "will only ever be non-negative", but phrased better).

(That section of the book isn't talking about NonZero.)

5

被遮蔽的原始变量并没有替换。 用汇编就可以推出来。
替换 这是不可能的。因为变量大小不一样。在栈上你还能硬替换？
销毁的话也不是。因为设计和性能。

6

I guess the assumed mental model here is that 0 would be both positive and negative. Here's where I'm coming from with this thought:

The section aims to explain the notion of "signed" based on writing down numbers on paper.

When writing down numbers on paper, you can write things with a sign, like +123 or -456 (in which case the sign explains the direction to move into from the origin [zero] to reach the number), or without one like 78 in which the convention is to assume it means +78.

Number encoding is based on the assumption that you either always write signs or never write signs. What "always writing signs" would mean for 0 is to write +0 or -0. Which both works (and unlike any other number, actually results in one and the same value).[1]

More accurate terminology would probably be something like "with a plus sign" instead of "positive", and "with a minus sign" instead of "negative" if we really are discussing written sign prefixes.

Or course you are correct about the established mathematical definitions of "positive" or "negative". Indeed Rust itself is offering API that follows that convention correctly (as expected).

On the other hand, exposatory - beginner-friendly material sometimes needs to over-simply for understandability. We cannot possibly use the word "non-negative" here instead.

I could see a case for considering adding "or zero", so turning it into "positive or zero". It's not the most important thing to clarify though anyway since right after it in the book they even specify the exact ranges of every unsigned and signed type.

The connection to mathematics is also limited. For example, a signed 123_i32 vs an unsigned 123_u32 refer to the same mathematical number, but are pretty different things in Rust because they're values of entirely different types! Well.. at the abstract level at least they are different; in bits in registers they do end up looking the same again. Talking about bit representations though, signed numbers are actually represented in a way that clearly makes zero more similar to all the other positive numbers and more different from the other negative numbers.

Also, while I can appreciate the (mathematically accurate) nit personally, I'm aware of many many inaccuracies in wording in the Rust book, so I'm not super hopeful that there are going to be changes to fix this particular case because it might mostly just complicate things to try being more accurate here.

Anyway, there's many over-simplifications to be found in the book "The Rust Programming Language" about other things, too. (For instance around the rules of borrowing.)
If keep on diving deeper into how Rust works and you ever come to look back later their descriptions in the book in the future, you'll probably be able to notice them too.

  1. we shouldn't let IEEE 754 floating-pont numbers get away with softening up this truth! /s ↩︎

7

Well, as far as I can see, numbering is a pretty mess thing in the world of programming and standards...
@steffahn has already discussed in detail about the mental model of rust on this issue which I will not repeat again. But to be honest on a broader prospective, especially often in the IEEE standards of encodings formats, +0 and -0 comes down to different bits; even NaN has tens of hundreds of different expressions in many format. So, it is really necessary to be more precise in discribing this. But, well, the book and the Rustonomicon and many of our great tutorials all have many places that are over simplified or not so persice... So, well, we need to be really careful when understanding.
And as far as I can see, even in china main land, the sort of 0 has changed many times in the last 20 years in basic educations. Different countries also has different educational diffinitions, and, just understand the rust way and not over thinking it too much might be better.
中文翻译的话我还是就不放了因为有点长...