Literals and operators - Wording - need to tell the compiler the type

[manoharreddyporeddy]

Please review below for any doc changes needed

At https://doc.rust-lang.org/rust-by-example/primitives/literals.html It says We need to tell the compiler the type of the literals we use. I felt that is must or have to ( though it dint say so ), otherwise may tell or could tell can be used

However, it works without telling the type There is no need to tell, it can infer. So doc should be changed?

==

// Integer addition
println!("1 + 2 = {}", 1 + 2);       // =============== i wrote this
println!("1 + 2 = {}", 1u32 + 2);

1 + 2 = 3 // =============== i wrote this 1 + 2 = 3

==

[marioidival]

Given the context of the subject, I think this sentence is fine, since the subject is about literals. Rust can infer types, as you have proven, but in my opinion, because of the context of the page, I would not change this sentence.

What do you think?

[manoharreddyporeddy]

The current documentation suggests that specifying the type is mandatory, which isn't always the case due to Rust's type inference capabilities. As someone with experience in over 40 programming languages, I found this misleading.

Rust can infer types, and many learners might come directly to this page without prior context. It's important for the documentation to be clear and unambiguous.

To avoid confusion, I recommend clarifying that while the compiler can infer types, specifying them can sometimes help avoid ambiguity:

While the Rust compiler can often infer the type of literals based on context, it is sometimes necessary to specify the type explicitly to avoid ambiguity. For now, we'll use the u32 suffix to indicate that the literal is an unsigned 32-bit integer, and the i32 suffix to indicate that it's a signed 32-bit integer.

In the end, documentation has to educate on something without ambiguity.

I hope the Rust team will consider this suggestion for the benefit of future learners. As I need to focus on other priorities, I won’t be able to provide further comments on this issue.

[marioidival]

@manoharreddyporeddy sure, it's a good one. Can you open the PR updating that sentence?