2013/4/10 Manu <turkeyman@gmail.com>

Why are you suggesting changing scope to imply ref? This seems wrong. scope and ref are separate, should remain that way.

I say that 'scope' itself should not imply 'ref'. It is *possible* but would break existing code meaning, so it should not be applied.

Arguments would be scope ref, or in ref, thus allowing rvalues. Without ref, I would imagine that the meaning is such that, even though the argument is a copy, it, or members thereof are not allowed to escape.

struct X { int *p; }

int* global;

void func(scope X x) // note: is not ref

{

  global = x.p; // <- error! scope prevents any part of x escaping, even though it's a copy.

}

This way, scope has meaning with or without ref.

That is an enhancement. Similar things is now in my mind, but it is not yet output.

And, 'scope' is alredy used for delegate parameter.

int opApply(scope int delegate(ref int) dg);

Such a semantic modification will silently change the meaning of existing code. It's not good to me.

What does scope mean in this case? Is this a conflict in some way?

Compiler guarantees that given delegate to the scope parameter never make a closure.

It would avoid heap allocation.