Jarrett Billingsley wrote:
> So my suspicion is correct, then?  That is:
> 
> scope int delegate() b;
> b = { ... };
> 
> Will allocate on the heap?

Yes. The scope for delegates takes effect as a parameter storage class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

"Walter Bright" wrote
> Jarrett Billingsley wrote:
>> So my suspicion is correct, then?  That is:
>>
>> scope int delegate() b;
>> b = { ... };
>>
>> Will allocate on the heap?
>
> Yes. The scope for delegates takes effect as a parameter storage class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Why?  It would be useful to allow local scope delegates.

The compiler can just forbid passing the delegate to a function which does not declare its parameter as scope.  I assume the compiler knows a variable is scope since it must prevent escape of the delegate, no?  So just use that information.  I thought that was the point of all this...

-Steve

Steven Schveighoffer wrote:
> "Walter Bright" wrote
>> Jarrett Billingsley wrote:
>>> So my suspicion is correct, then?  That is:
>>>
>>> scope int delegate() b;
>>> b = { ... };
>>>
>>> Will allocate on the heap?
>> Yes. The scope for delegates takes effect as a parameter storage class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.
> 
> Why?  It would be useful to allow local scope delegates.
> 
> The compiler can just forbid passing the delegate to a function which does not declare its parameter as scope.  I assume the compiler knows a variable is scope since it must prevent escape of the delegate, no?  So just use that information.  I thought that was the point of all this...

In order to make that work, the compiler would have to do full escape analysis, which is a lot of work to implement.

Walter Bright:
> In order to make that work, the compiler would have to do full escape analysis, which is a lot of work to implement.

But the D2 programmer may enjoy some ways to state what he/she/shi wants anyway, like in a cast, to make the compiler behave like the D1 compiler and avoid a slowdown. And such ways have to be intuitive enough to use.

Bye,
bearophile

On Thu, 27 Nov 2008, Walter Bright wrote:

> Jarrett Billingsley wrote:
> > So my suspicion is correct, then?  That is:
> > 
> > scope int delegate() b;
> > b = { ... };
> > 
> > Will allocate on the heap?
> 
> Yes. The scope for delegates takes effect as a parameter storage class, not a local variable storage class. The reason is because it is the called function that decides what it's going to do with the delegate.

Walter, this is yet more evidence that shows that accepting and ignoring these sorts of modifiers is the wrong thing to do.  Accepting dubious definitions like 'public private int foo' and the above make life harder than it needs to be.

Later,
Brad

Brad Roberts:
> Walter, this is yet more evidence that shows that accepting and ignoring these sorts of modifiers is the wrong thing to do.  Accepting dubious definitions like 'public private int foo' and the above make life harder than it needs to be.

I agree. What's the rationale behind accepting things and later ignoring them?
(Maybe to allow a different D compiler to compile code even if can't manage every one of those modifiers?)

Bye,
bearophile

Brad Roberts wrote:
> Accepting dubious definitions like 'public private int foo' and the above make life harder than it needs to be.

The code:

public private int foo;

produces the error message:

test.d(1): redundant protection attribute

Walter Bright wrote:
> 
> http://www.digitalmars.com/d/1.0/changelog.html
> http://ftp.digitalmars.com/dmd.1.037.zip
> 
> 
> 
> http://www.digitalmars.com/d/2.0/changelog.html
> http://ftp.digitalmars.com/dmd.2.021.zip
> 
I have put some comments against #2429 which is improved, but not quite right. I get the impression that no so many people are using the phobos library these days, and won't notice such things.

Robert Jacques wrote:
> Just as a point of reference (in D1)
> scope Object a = new Object(); // Stack Allocated
> scope Object b;
> b = new Object(); // Heap Allocated
> 
> So there may be some merit to scope int b() { .. } vs scope int b(); b = {...}

I can't find any spec on exactly how scope works, but this makes 100% sense to me.  Let me explain the way that I think scope does/might/should work:

The thing to remember is that "scope" is *not* transitive.  Scope limits the most shallow reference, *not* not anything deeper.  It is perfectly valid to have a scope pointer to a non-scope thing.  The point of scope is to enforce that the pointer cannot escape; it does not say anything about whether the pointed-to object escapes or not.

The point then, is that you can create a non-scope object, and assign it to a scope pointer.  When you do something like:

BEGIN CODE
	scope <type> a;
	a = <allocate thing>;
END CODE

...you are doing exactly that.

(At least, that's how I think it ought to work.)

Mon, 01 Dec 2008 10:26:31 -0700, Russell Lewis wrote:

> The thing to remember is that "scope" is *not* transitive.  Scope limits the most shallow reference, *not* not anything deeper.  It is perfectly valid to have a scope pointer to a non-scope thing.  The point of scope is to enforce that the pointer cannot escape; it does not say anything about whether the pointed-to object escapes or not.
> 
> The point then, is that you can create a non-scope object, and assign it to a scope pointer.  When you do something like:
> 
> BEGIN CODE
> 	scope <type> a;
> 	a = <allocate thing>;
> END CODE
> 
> ...you are doing exactly that.
> 
> (At least, that's how I think it ought to work.)

http://www.digitalmars.com/d/1.0/attribute.html#scope

Originally, the scope keyword wasn't about escaping, it was about memory management.  The code

  scope C c = new C;

was a sugar for

  C c =new C;
  scope(exit) delete c;

The spec says, "Assignment to a scope, other than initialization, is not
allowed."  Therefore your example is illegal.  I think the fact that DMD
accepts such a code is a bug.  I'll file a bug report.