Release D 2.094.0

Meta jared771 at gmail.com
Thu Oct 1 16:47:37 UTC 2020


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?

> 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.

> -Steve




More information about the Digitalmars-d-announce mailing list