Const ref and rvalues again...

[Manu]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20121106/67b3a4ea/attachment.html>