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 <[email protected]> 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 >
