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
