3 ms·

It’s also worth noting that in rust you don’t need to be as worried about marking a function #[must_use] if there is a valid reason some of the time to discard

by bayesnet 10mo ago

It’s also worth noting that in rust you don’t need to be as worried about marking a function #[must_use] if there is a valid reason some of the time to discard the value. One can just assign like so `let _ = must_use_fn()` which discards the value and silences the warning. I think this makes the intent more clear than casting to void as TFA discusses.

on_the_train 10mo ago
There is in c++, too (std::ignore). Not sure why the author decided to go with the ancient void cast
- aw1621107 10mo ago
  I believe C++26 now allows _ as a placeholder name [0]: > We propose that when_ is used as the identifier for the declaration of a variable, non static class member variable, lambda capture or structured binding. the introduced name is implicitly given the [[maybe_unused]] attribute. > In contexts where the grammar expects a pattern matching pattern,_ represents the wildcard pattern. Some of the finer details (e.g., effect on lifetime and whether a _ variable can be used) differ, though. [0]: https://github.com/cplusplus/papers/issues/878 https://github.com/cplusplus/papers/issues/878
  - tialaramex 10mo ago
    Specifically, Rust's _ is not a variable, it is a pattern that matches anything and so let _ = isn't an assignment it's specifically the explicit choice not to assign this value. If we wrote a "dummy" variable the compiler is forbidden from dropping the value early, that "dummy" is alive until it leaves scope, whereas if we never assigned the value it's dropped immediately. In modern Rust you don't need the let here because you're allowed to do the pattern match anywhere, and as I said _ is simply a pattern that matches anything. So we could omit the let keyword, but people don't.
- vitus 10mo ago
  std::ignore's behavior outside of use with std::tie is not specified in any finalized standard. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2968r2.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p29... aims to address that, but that won't be included until C++26 (which also includes _ as a sibling commenter mentions).
- quuxplusone 10mo ago
  https://quuxplusone.github.io/blog/2022/10/16/prefer-core-over-library/ https://quuxplusone.github.io/blog/2022/10/16/prefer-core-ov... does not (yet) include this as one of its examples, but it could (and someday might).
OptionOfT 10mo ago
Careful. I don't like the use of `let _ =` in general, as it instantly drops. And you don't get a compilation failure when the type on the right hand side changes. This is even more important if it switches from non-drop to drop. There is a clippy lint for this.
- junon 10mo ago
  Good point. You can always explicitly type the underscore. Clippy even has `let_underscore_untyped` for this. Never thought about it, but I'll be adding this to my standard list of deny lints now.

on_the_train 10mo ago

There is in c++, too (std::ignore). Not sure why the author decided to go with the ancient void cast

aw1621107 10mo ago
I believe C++26 now allows _ as a placeholder name [0]: > We propose that when_ is used as the identifier for the declaration of a variable, non static class member variable, lambda capture or structured binding. the introduced name is implicitly given the [[maybe_unused]] attribute. > In contexts where the grammar expects a pattern matching pattern,_ represents the wildcard pattern. Some of the finer details (e.g., effect on lifetime and whether a _ variable can be used) differ, though. [0]: https://github.com/cplusplus/papers/issues/878 https://github.com/cplusplus/papers/issues/878
- tialaramex 10mo ago
  Specifically, Rust's _ is not a variable, it is a pattern that matches anything and so let _ = isn't an assignment it's specifically the explicit choice not to assign this value. If we wrote a "dummy" variable the compiler is forbidden from dropping the value early, that "dummy" is alive until it leaves scope, whereas if we never assigned the value it's dropped immediately. In modern Rust you don't need the let here because you're allowed to do the pattern match anywhere, and as I said _ is simply a pattern that matches anything. So we could omit the let keyword, but people don't.
vitus 10mo ago
std::ignore's behavior outside of use with std::tie is not specified in any finalized standard. https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2968r2.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p29... aims to address that, but that won't be included until C++26 (which also includes _ as a sibling commenter mentions).
quuxplusone 10mo ago
https://quuxplusone.github.io/blog/2022/10/16/prefer-core-over-library/ https://quuxplusone.github.io/blog/2022/10/16/prefer-core-ov... does not (yet) include this as one of its examples, but it could (and someday might).

OptionOfT 10mo ago

Careful. I don't like the use of `let _ =` in general, as it instantly drops. And you don't get a compilation failure when the type on the right hand side changes. This is even more important if it switches from non-drop to drop. There is a clippy lint for this.

junon 10mo ago
Good point. You can always explicitly type the underscore. Clippy even has `let_underscore_untyped` for this. Never thought about it, but I'll be adding this to my standard list of deny lints now.