The liabilities of binding rvalues to ref

[Manu]

On 10 May 2013 09:20, Rob T <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.

the scope ref proposal does not interfere with scope as originally
intended, it is a natural extension of the concept... unless I don't
understand scope as originally intended properly (which is possible, it's
barely documented).

In any event  you may want to use scope ref to prevent escapes and also
> refuse to use rvalues, so it is not a good solution for that reason alone.


Why? Why would a function want to receive a temporary but not an implicit
temporary?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130510/e915da6c/attachment.html>