escaping pointer to scope local array: bug or not?

[Steven Schveighoffer]

On Mon, 17 Aug 2009 16:51:20 -0400, Hosokawa Kenchi <hskwk at inter7.jp>  
wrote:

> Robert Fraser Wrote:
>
>> HOSOKAWA Kenchi wrote:
>> > It seems dmd 2.031 forgets scope attribute for array.ptr in some  
>> cases, so that it allows escaping a pointer to scope local array.
>> > I'm not sure this is a bug or a kind of "dangerous-but-valid".
>>  >
>> > int* ap()
>> > {
>> > 	scope auto a = new int[1];
>> > 	return a.ptr; // no error; this is the problem
>> > }
>>
>> Probably should be an error, but, FWIW, scope arrays are still
>> heap-allocated (yeah, I know it's inconsistent). So there's no chance of
>> memory corruption, etc.; it's as if you didn't have the "scope" there.
>>
>
> I'd tried to check where 'scoped' variables are on the Jacques's advice.
> As a result, I reached the same conclusion to yours.
> They are heap-allocated, of course, would not be collected by GC (I'm  
> not sure collect-proofness is guaranteed or not).
>
> I suppose semantics of 'scope' is still ambiguous.
>
> int[] f() {
> 	scope x = new int[6];
> 	auto y = x[1..3];
> 	return y;			//	no error, successfully escape slice-reference of  
> 'originally' scoped array.
> }
>
> I'm unable to make a quick decision that it SHOULD be error or not.
> I wish here is a opinion which gives clear cut on this issue.

remember, scope is a storage class, not a type modifier.  "scopeness" is  
only a hint to the compiler of where to store it originally, the hint is  
not passed on to other variables which point to the same data.  I'm  
surprised it's actually an error to try and return a scope variable.

One way to get scope to work as you desire is to make it a type modifier  
and define rules about assignment, but I'm not sure that's a good answer.   
Another way is to perform escape analysis, but Walter has expressed that  
he doesn't want to do that.  It would require an intermediate interface  
language for imports where annotations could be added by the compiler.

-Steve