Release D 2.094.0

[Petar]

On Thursday, 1 October 2020 at 16:47:37 UTC, Meta wrote:
> On Thursday, 1 October 2020 at 16:19:48 UTC, Steven 
> Schveighoffer wrote:
>> On 10/1/20 10:36 AM, Meta wrote:
>>> On Thursday, 1 October 2020 at 09:49:36 UTC, Mathias LANG 
>>> wrote:
>>>> Author here. The most complete way to know would be to read 
>>>> the changelog: 
>>>> https://dlang.org/changelog/2.094.0.html#preview-in
>>>> The TL;DR is that, in addition to `const scope`, `in` now 
>>>> automatically behaves as `ref` when "it makes sense" such as 
>>>> large value types or presence of destructors / postblit 
>>>> (more details in the changelog!) and will accept rvalues, 
>>>> unlike other ref parameters.
>>> 
>>> Why was this added when we already have `auto ref`? Yes, it 
>>> makes the function a template, but if `in` can automatically 
>>> choose whether the variable is ref or not, then auto ref 
>>> could easily do the same.
>>
>> 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?

`auto ref` is a mistake and shouldn't have existed. Thanks to 
Mathias, `in` parameters are finally working the way most sane 
people expect them to work.
I can't quite explain `auto ref` with straight face, while to 
explain `in` I just need to say "unless you're mutating or 
aliasing the parameter always mark it as `in`".

>> Not only that, but every auto-ref parameter is another 
>> template parameter varying on the usage. So calling on an 
>> lvalue and rvalue will generate 2 separate mostly-identical 
>> functions.
>>
>> With -preview=in, only one function is generated per type.
>
> That's a QOI problem IMO.
>

No, it's not. According the spec, `auto ref` parameters can only 
be used for templates (making them useless for virtual functions 
and delegates) and the compiler is required to generate a 
different functions depending on whether the parameter is an 
lvalue or an rvalue, which completely misses the point. There's 
code out there that expect two instances to be generated and 
distinguishes which one it's in using `static if (__traits(isRef, 
param))`. You can't change this behavior without breaking code, 
so it's not a QoI problem.

On the other hand, now the `in` parameter storage class finally 
has the opposite meaning of `out`. Makes code more elegant to 
write, easier to explain and teach.