auto ref is on the docket

[Jonathan M Davis via Digitalmars-d]

On Tuesday, 23 June 2015 at 19:13:28 UTC, bitwise wrote:
> And I still think Timon's statement is untrue. There is a 
> reason, which is that the new auto ref syntax forces reference 
> parameters for all types(even primitives), where the old 
> template approach does not.

The "old template approach" isn't going anywhere. When used with 
templated functions, auto ref will continue to function the same 
way, and if you want that behavior, you templatize your function. 
AFAIK, there are really only two ways to tackle having a function 
accept both lvalues and rvalues for the same parameter:

1. Duplicate the entire function and have one overload take an 
lvalue and the other take an rvalue. This is what the the 
templated auto ref does (though which overloads get generated 
depends on what arguments are passed to the function).

2. Assign rvalues to an lvalue and pass that in to the function 
by ref. This is what's going to happen with non-templated 
functions. It's just a question of whether that's going to be 
done by introducing a temporary variable or by having the 
compiler add overloads which take rvalues and then call the 
primary function which takes its arguments by ref.

And at this point, I think that there are really only three 
options that we might take in making it so that we can have 
non-templated functions accept both lvalues and rvalues with the 
same function declaration:

1. Leave things as they are and not support it except with 
templated functions (not desirable, but that may be the result of 
all of this).

2. Implement auto ref for non-templated functions as currently 
proposed, leaving auto ref on templated functions exactly as it 
is and providing no way to use the non-templated behavior with 
templated functions (though _maybe_ we could add compiler 
optimizations later to use the non-templated version in cases 
where the compiler can detect that using the non-templated 
version with a templated function would have the same semantics 
as the templated version).

3. Add a new attribute which does what's being proposed for auto 
ref for non-templated functions, in which case, we can use the 
non-templated behavior with templates as well and thus avoid 
template bloat when all you want is for your templated function 
to accept both lvalues and rvalues. auto ref, of course, then 
stays exactly as it is now.

At the moment, it seems that #2 is the most likely, and that's 
probably fine, but I do wonder if we'd be better off with #3, 
especially when you consider how much D code tends to be 
templated and how much code bloat auto ref is likely to generate 
with templated functions.

- Jonathan M Davis