Const ref and rvalues again...

[Jonathan M Davis]

On Sunday, November 11, 2012 13:30:12 Manu wrote:
> What do you mean 'aren't really references in the normal sense'?

ref is not really part of a variable's type. It's just a storage class and is 
really only applicable in very specific circumstances. A function parameter is 
a local variable, but ref makes it so that it just so happens to affect a 
variable outside the function as well. The semantics of the function itself or 
how the parameter is used aren't any different either way. So, if you were to 
remove ref from the parameter, the function itself would be unaffected 
semantically-speaking (it would affect the code generation some though). It's 
the caller whose semantics change.

This is in direct contrast with a pointer or reference type where the fact 
that it refers to something else outside the function is fully part of the 
type.

Taking the address of a local variable is already something that is incredibly 
unsafe and doesn't work. So, anyone doing it is being an idiot anyway. And if 
it's _always_ stupid, then protecting it with scope isn't really necessary. 
pure mostly stops anything like that from happening in the general case, but 
doesn't prevent people from doing stupid stuff like

int* foo() pure
{
    int i;
    return bar(&i);
}

int* bar(int* p) pure
{
    return p;
}

Regardless, my point was that the refness of the parameter isn't really part 
of the type of the parameter, whereas all other issues with reference escaping 
that scope would affect _are_ part of the type. So, you're talking about scope 
protecting against something quite different from what it would protect from in 
all other circumstances. Protecting against escaping a ref parameter and a 
reference type escaping are two different (albeit not completely unrelated) 
things.

Honestly, before you brought up the possibility of scope protecting against 
pointers to ref parameters escaping, it had never occurred to me. I've never 
seen anyone bring it up before. And as you're talking about protecting against 
escaping a pointer to a local variable, which is an incredibly stupid thing to 
do anyway, I'm not sure that the protection is really needed.

But I don't know what Walter's or Andrei's intentions were with regards to 
whether scope would extend to the fact that the parameter is ref. I don't 
think that it's necessarily the case that it wouldn't, but you're then 
protecting against escaping a pointer to a local variable (albeit one which 
affects a variable outside of the function) rather than against escaping a 
reference type. And from everything I've seen, it's protecting against 
escaping reference types which was its purpose.

Unfortunately, TDPL doesn't seem to discuss scope parameters at all (I thought 
that it did, but I can't find it anywhere now if it does), meaning that the 
online docs are the only official documentation on scope, and all other 
information on it comes from newsgroup discussions on the matter. It's quite 
possible that many of us have misunderstood aspects of what scope parameters 
were intended to do.

So, assuming that if/when scope actually starts affecting more than delegates 
as quite a few us think that it's supposed to do, then what you're looking for 
may very well be on the table, much as I wouldn't have expected it to be. I 
don't know.

Feel free to create an enhancement request for it. Even it wasn't part of the 
original intention of scope parameters, Walter may think that it's worth 
making it so that it is.

> That would be the point though. If you don't want that, then you don't want
> scope.

The problem is that in most cases, I really don't think that that is what the 
average programmer wants, and there _are_ people who use in as a matter 
course. It would be one thing if you had to explicitly use scope, then I 
suspect that it wouldn't be used as a matter of course by much of anyone. For 
the most part, it would then just be used when the programmer knew that that's 
what they wanted. But with in, so many people seem to really like the concept 
of it being the opposite of out that they use it as a matter of course without 
understanding the consequences.

- Jonathan M Davis