On 10/1/20 12:47 PM, Meta wrote:
On Thursday, 1 October 2020 at 16:19:48 UTC, Steven Schveighoffer wrote:
There is a difference. `in` is choosing it based on the type, not
whether it's an rvalue or lvalue. auto ref doesn't care whether it's
an int or a 1k-sized struct, if it's an lvalue, it's ref, and if it's
an rvalue, it's non-ref.
This seems ridiculous to me. We now have ANOTHER way of asking the
compiler to choose for us whether to pass by ref or by value, completely
mutually exclusive of auto ref. Where was the DIP (apologies if I just
didn't see it)? Did Walter approve this? How do we explain the
difference between in and auto ref with (as Andrei would say) a straight
face?
Whether a *const* piece of data is passed by reference or value is an
implementation detail -- you can't change it anyway. I don't want the
compiler to pass const integers by reference -- that's wasteful.
auto ref is a different problem -- the data might be mutable, which
makes an actual difference in semantics.
But this brings up a problem which I don't know if it was discussed --
aliasing.
What if you pass in the same value in 2 parameters, one ref and one in.
And you change the value via the ref. What happens to the in parameter?
-Steve