Release D 2.094.0

[Steven Schveighoffer]

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