Yeah I really don't understand how 'auto ref' entered this conversation? It completely misses the point.

The issue as I see it is this:
  void func(ref in Vector m);
  func(v1*v2 + Vector(10, 20, 30));

And countless situations like it, all leading to innumerable temp locals with irrelevant names:
  Vector v1v2PlusSomeStuff = v1*v2 + Vector(10, 20, 30);
  func(v1v2PlusSomeStuff);

Or even:
  Vector initialiser1 = Vector(10, 20, 30); // <- words can scarcely describe how annoying this is
  func(initialiser1);

Allowing rvalues to be passed by ref is exactly as unsafe as those examples, and that workaround is employed every time anyway, so the restriction is self-defeating.


On 5 November 2012 10:01, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
On Monday, November 05, 2012 06:05:07 Rob T wrote:
> On Monday, 5 November 2012 at 03:26:10 UTC, Jonathan M Davis
>
> wrote:
> > And when we argued for altering it so that it operated like
> > const ref in C++
> > (which allows const ref in D to continue to function like it
> > does now), some
> > folks complained, because they've found the current semantics
> > of auto ref to
> > be useful (something to do with propagating the exact, original
> > type, I
> > think).
>
> I would expect that auto ref for a template and for a non
> template should work in exactly the same way, so why would there
> be a difference? If there must be a difference, there should be
> different semantics for specifying the difference, otherwise the
> inconsistent behaviours among identical semantics will only serve
> to confuse people.

auto ref's current semantics can't possibly work with non-templated functions,
and it's clear that there are good reasons for keeping auto ref as it is now
for templates. So, either we make it work with non-templated functions with
different (albeit similar) semantics, or we need a new attribute for doing what
we want to do with non-templated functions.

- Jonathan M Davis