On 06/25/2015 10:28 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?=
<[email protected]>" wrote:
trying to expand it with "scope ref" as if that were simply an
extension of scope makes no sense. Before we can even consider what
something like scope ref might mean, we'd have to properly define what
scope means. And all we have for it is the basic idea of what it's
supposed to do - none of the details - and trying to define scope ref
before defining what scope means in general could totally hamstring us
when properly defining scope later.
I can assure you that it will not limit us. The very concept of
borrowing/scope already requires some very specific restrictions with
regards to what a function is allowed to do with a scope parameter.
These same restrictions guarantee that it's allowed to pass an rvalue to
it. Every working scope proposal will always guarantee that, or it
wouldn't be usable.
If you still fear that it will impede us later, then at least this
current proposal needs to be deferred until we have a scope proposal and
have decided on it.
I think the arguments against allowing rvalues with scope ref are the
same as those against allowing rvalues with ref, modulo accidental
escaping. (It has been argued that 'ref' signifies an intent to modify,
which I wouldn't necessarily agree with.)
