Hacker News Reader

Comment by b5n | Hacker News Reader

> -Wconversion ... assumes converting 1000.0 to 1000 is ok due to no loss in precision.

Additionally, `clang-tidy` catches this via `bugprone-narrowing-conversions` and your linter will alert if properly configured.

View on HN

My opinion is that if you need to run extra tools/linters in order to catch basic errors, the language & its compiler are not doing enough to protect me from correctness bugs.

I do run clippy on my Rust projects, but that's a matter of style and readability, not correctness (for the most part!).

How much of what Rust the language checks is actually linter checks implemented in the compiler?

Conversions may be fine and even useful in many cases, in this case it isn’t. Converting to std::variant or std::optional are some of those cases that are really nice.

There's a bit more nuance here than 'basic errors', and modern c compilers offer a lot of options _if you need to use them_.

I appreciate that there are guardrails in a tool like rust, I also appreciate that sharp tools like c exist, they both have advantages.

To be clear, the only difference between Rust and C here is whether the conversion happens by default or not. Rust doesn't do the conversion by default but will let you do it if you want to, with `as`.

There are also more type-safe conversion methods that perform a more focused conversion. Eg a widening conversion from i8 -> i16 can be done with .into(), a narrowing conversion from i16 -> i8 can be done with .try_into() (which returns a Result and forces you to handle the overflow case), a signed to unsigned reinterpretation like i64 -> u64 can be done with .cast_unsigned(), and so on. Unlike `as` these have the advantage that they stop compiling if the original value changes type; eg if you refactor something and the i8 in the first example becomes an i32, the i32 -> i16 conversion is no longer a widening conversion so the `.into()` will fail to compile.

That's funny, if memory serves 'as' should be avoided in Rust and other casts should be used. That's a Rust wart which cannot be fixed..

Yes that's correct, for exactly the reason that it is more likely to keep compiling and possibly not do what you intended if the original value's type changes due to refactoring. However there are still a few conversions that don't have alternatives to `as` - truncating conversions (eg i64 -> i32 that intentionally discards the upper half), int <-> float conversions (eg i64 -> f64, both truncating and checked conversions), unsized pointer casts (eg *const [MaybeUninit<u8>] -> *const [u8], `.cast()` only works for Sized target), and probably a few more.

Setting up clang-tidy for your IDE isn't really any more trouble than setting up a LSP. If you want the compiler/linter/whatever to reject valid code to protect you from yourself, there are tools you can use for that. Dismissing them just because they aren't part of the language (what, do you expect ISO C++ to enforce clang-tidy usage?) is silly.

I beg to differ, the same reasoning applies to Rust, otherwise there would not be a clippy at all.

The reason certain warnings are on or off by default in compilers in certain warnings modes depends on whether enough people find them useful enough or not. Rust caters to people who want strictness which makes it annoying to use for others, but if you want this you can also - to a large degree - have this in C and C++.

Reply on news.ycombinator.com