Say I have a struct that provides a method that does some work (has useful side effects) and then returns an instance of itself. Do I have to use that instance somehow in order to guarantee that the code having the side effects will execute?
As per C++ standard, RVO and NRVO can elide the "as-if" rule. However, I'd expect different behavior from Rust, especially when using the _ = ... idiom. Now I'm wondering if I'm wrong in doing so.
To give a concrete example, let's look at the esp_hal::gpio::Io::new() which calls Self::new_with_priority() and before returning an instance of itself sets up the io-driver as a side effect. Can I then use the function for its side effects, but explicitly discard the returned object, like so:
let _ = esp_hal::gpio::Io::new();
In contrast to C++, I'd expect the compiler to not elide the side effects. Furthermore, I would expect it to elide the construction of an Ioinstance. In fact, that's exactly how I'd interpret the semantics/intent behind the _ = ... idiom. Should I update my beliefs?
It's important to note that you can destructure with let. More generally, you can pattern-match with let as long as the pattern is irrefutable.
_ is the pattern that means "match anything at all and don't bind it." In other words, anything that matches _ in a pattern will be dropped.
So we can infer from this that let _ = anything(); is almost1 semantically identical in every way to just anything();. Using let _, the value returned from anything() is dropped because of the behavior described above. Not using let _, the value returned from anything() is dropped at the end of the statement because it is an unused temporary value.
All that to say, it doesn't much matter whether you say let _ = function(); or just function();. In terms of what happens to the function's return value, they do the same thing at the same point in time.
Additionally, Rust doesn't have a special notion of constructors like C++ does. Functions that create values can be called "constructor functions" but this is just terminology; at the language level, there is no conceptual difference between a function that creates a Self or any other function.
Rust also doesn't have a concept of pure functions or those with side effects. If a function is actually pure and the result is unused, the optimizer might be able to determine that the whole thing is a giant no-op, but if the function does have side effects, such as mutating state or doing I/O, the optimizer will be unable to elide the function call in its entirety.
The summary is that the compiler is not going to optimize away that function call, assuming it does have observable side effects2. This is true regardless of whether or not you use the let _ syntax.
1 The "almost" is that let _ = y; counts as a usage of y, while y on its own does not. This is commonly used to ignore Results returned from a function when one does not care if the operation failed. let _ = fallible_operation(); will suppress the "unused Result that must be used" warning.
2 As a curiosity, note that Rust does not consider allocation to be a side effect, and therefore allocations can be optimized away in some cases.