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[] a()
{
	scope auto a = new int[1];
	return a; // error; escaping reference to scope local array
}

int* ap()
{
	scope auto a = new int[1];
	return a.ptr; // no error; this is the problem
}

int* i()
{
	int i;
	return &i; // error; escaping reference to local variable
}

int* ip()
{
	scope int* p = new int;
	return p; // no error; only is "int* p" local, "new int" not scope local?
}

On Sun, 16 Aug 2009 10:13:42 -0700, HOSOKAWA Kenchi <hskwk@inter7.jp> 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[] a()
> {
> 	scope auto a = new int[1];
> 	return a; // error; escaping reference to scope local array
> }
>
> int* ap()
> {
> 	scope auto a = new int[1];
> 	return a.ptr; // no error; this is the problem
> }
>
> int* i()
> {
> 	int i;
> 	return &i; // error; escaping reference to local variable
> }
>
> int* ip()
> {
> 	scope int* p = new int;
> 	return p; // no error; only is "int* p" local, "new int" not scope local?
> }
>

I'd recommend checking to see if p* was allocated on the stack or on the heap, as the difference represents two very different bugs.

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.

On Sun, Aug 16, 2009 at 1:13 PM, HOSOKAWA Kenchi<hskwk@inter7.jp> wrote:
>        scope auto a = new int[1];

Just for future reference, "scope auto" is redundant.  "auto" does not mean "infer the type"; the absence of a type is enough to do that. "auto" is just the default storage class.  "scope a = new int[1];" will work fine (as will "const a = 4;" "static a = 5;" etc.).

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.

Jarrett Billingsley Wrote:

> On Sun, Aug 16, 2009 at 1:13 PM, HOSOKAWA Kenchi<hskwk@inter7.jp> wrote:
> > &#63728; &#63728; &#63728; &#63728;scope auto a = new int[1];
> 
> Just for future reference, "scope auto" is redundant.  "auto" does not mean "infer the type"; the absence of a type is enough to do that. "auto" is just the default storage class.  "scope a = new int[1];" will work fine (as will "const a = 4;" "static a = 5;" etc.).

Thanks for the nice advice.
Now I become more familiar with D!

On Mon, 17 Aug 2009 16:51:20 -0400, Hosokawa Kenchi <hskwk@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

Steven Schveighoffer:
> 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.

Why is that bad?

Bye,
bearophile

On Tue, 18 Aug 2009 13:34:36 -0400, bearophile <bearophileHUGS@lycos.com> wrote:

> Steven Schveighoffer:
>> 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.
>
> Why is that bad?

I don't think it's bad, but definitely a lot of work.  I would be all for it.

-Steve

On Tue, 18 Aug 2009 10:38:50 -0700, Steven Schveighoffer <schveiguy@yahoo.com> wrote:

> On Tue, 18 Aug 2009 13:34:36 -0400, bearophile <bearophileHUGS@lycos.com> wrote:
>
>> Steven Schveighoffer:
>>> 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.
>>
>> Why is that bad?
>
> I don't think it's bad, but definitely a lot of work.  I would be all for it.
>
> -Steve

Actually, it's really bad. Escape analysis requires whole program analysis. It would be impossible to do incremental compilation or to ship/sell D libraries in binary format. I'd recomend checking out http://en.wikipedia.org/wiki/Escape_analysis for an overview of the issues involved. You can avoid doing whole program analysis by introducing ownership types and being a bit conservative in what you allow. There's a (bit confusing) wiki page proposal an how to implement it at http://www.prowiki.org/wiki4d/wiki.cgi?OwnershipTypesInD.