Hacker News Reader

Comment by csomar | Hacker News Reader

Numbers could also be differentiated in Rust. For example, to make sure your "16" is an i32 you could write

> let x: i32 = 16i32;

Otherwise, it's a very comprehensive article. The only missing parts are the async/await keywords and the sync primitives (like Mutexes/RwLocks).

View on HN

C# has a similar feature, but it's less verbose, e.g. "16l"/"16L" is a long (64-bit integer), "16u" is an unsigned, 32-bit integer etc.

I find the rust syntax a little difficult to read. Take "16i32" for example - it's not immediately clear which part is the actual value.

The problem with "long" "unsigned" "short" "long long", etc. in the C world is that they all can mean different things depending on the architecture and compiler. i32, u64, f32, etc. make it very explicit what sized object you're working with. I'm not sure that's hugely applicable in C# land as there's only, what, two compilers and two? three? hardware architectures supported.

I agree that something like 16i32 is difficult to read which is why I typically use an underscore to separate the number from the type if I need to write a literal that way (e.g. sometimes I find 0_f64 easier to grok than 0.0).

Not a problem with C#, but I recognise it's an issue with C.

I didn't know you could use an underscore to separate the type - I think that definitely helps!

One neat thing Rust let you do is put underscores in number literals. It's great for readibility:

    0xFFFF_FFFF // easier to count than 8 Fs

And you can use that with type suffixes:

    let a = 255_u8;

Although in that case, you'd probably either omit u8 entirely, letting the compiler infer the type of 'a' from usage, or use a colon to give it ane explicit type.

Type suffixes are especially useful for arguments to generic functions:

    write_le(12_u32);
    write_le(255_u8);

C# 7 (2017) and higher also allows underscores in number literals.

You can do the same thing with C#, which is great for groupings, e.g. "2000000" becomes "2_000_000".

As a rust noob, I didn't realise rust supported the same syntax, or that you could use it to separate the type from the value (which in rust's case, I find really helps readability).

You don't need both of those "i32"s. Rust has type inference, so you can just write either `let x = 16i32` or `let x: i32 = 16`.

I use it mostly if I'm passing arguments to another function. It serves as some sort of code documentation.

> my_function( 44i32 );

That makes it clear from the code that function accepts an i32 and not any number.

The type signature of the function will also enforce that.

You can also use generics to allow you to accept a wider variety of numbers, e.g.:

  fn takes_a_float_like_number<T>(number: T) where T: Into<f64> {
    // Number will now be a 64-bit IEEE floating point object
    // for this scope
    let number = number.into();
  }

This will only compile if your type is small enough to fit into an f64. So takes_a_float_like_number(500_u32) will compile but takes_a_float_like_number(500_i64) will not. The error message will be a wee bit obtuse as it will be something like "trait Into<f64> not implemented for i64".

How would you improve that error?

"Literal {} is too large for type {}" (or thereabouts) is how this is handled in C/C++ compilers. I think it is enabled by -Wall or -Wpedantic in clang.

In other languages I've seen something like "type {} can't represent literal of value {}" which is a bit more generic and applies to things like floats/signed ints and values that are too small/negative.

Also you can use underscores in numeric literals. So you can write

  let x = 65536_i32;

  let x: i32 = 65_536;

Reply on news.ycombinator.com