The liabilities of binding rvalues to ref

[Dmitry Olshansky]

10-May-2013 04:18, Manu пишет:
> On 10 May 2013 09:20, Rob T <alanb at ucora.com <mailto:alanb at ucora.com>>
> wrote:
>
>     On Thursday, 9 May 2013 at 22:42:14 UTC, Manu wrote:
>
>         And it's
>
>             even questionable that scope as originally intended can be
>             properly
>             implemented anyway.
>
>
>         ...so, the problem is no different than 'auto ref' as you
>         mention above.
>         It's not implemented as drafted, and we're debating what's actually
>         correct. Clearly the draft was incomplete in both cases.
>         I only support the proposal (from others) that scope ref makes
>         so much more
>         sense, and I think we've also proven it can be made to work
>         syntactically
>         without holes, which I don't believe is so for auto ref.
>
>
>     However despite the elusiveness of a solution, it looks like we'll
>     be able to implement auto ref as was originally intended. We may
>     also be able to implement scope as was originally intended, but not
>     if we use it for another purpose.
>
>
> Except that auto ref as originally intended seems to have been a flawed
> design, as evidenced by the massive waves this issue keeps creating.
>

Simply put it wasn't ever implemented like it was meant to.
When something doesn't exist it's hard to believe that its broken.

In fact I expected it to mean what you seem to attribute to scope ref 
i.e. ~ as C++ const& minus logical const part.
The desire to make 2 versions of function in template case is serving 
one use case only - perfect forwarding and IMO is hacky. Funnily tough 
this corner-case beast (for templates) is implemented and the chief 
usage (for normal functions) isn't.

-- 
Dmitry Olshansky