"Walter Bright" wrote
> 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.

Maybe I've misunderstood the point of declaring a delegate parameter scope.

Take the following example:

void delegate(int) global_dg;

void foo(void delegate(int) dg)
{
   global_dg = dg;
}

void foo2(scope void delegate(int) dg)
{
   dg(5);
}

void bar(scope void delegate(int) dg)
{
   foo(dg); // should this compile?
   foo2(dg); // should this compile?
}

void baz()
{
   int y;
   void dg(int x) { y += x; }
   bar(&dg);
}

Should bar's call to foo compile?  If it does, then the benefit of having scope delegates is just a hint to the compiler that "I know what I'm doing".

If it fails to compile the call to foo, what about the call to foo2?  If that fails to compile, then this is a common convention (forwarding a delegate) that will cause lots of problems in existing correct code.  If the call to foo2 should work, I don't see the difference between the above example and this:

void baz2()
{
   int y;
   void dg(int x) { y += x; }
   scope void delegate(int) dg2 = &dg;
   bar(dg2);
}

That is, if you can tell that a delegate is scope or not scope when it's being passed to another function, then why can't the compiler use that information when the delegate is assigned to another scope delegate?  No full escape analysis is needed.

-Steve

Mon, 1 Dec 2008 14:10:27 -0500, Steven Schveighoffer wrote:

> "Walter Bright" wrote
>> 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.
> 
> Maybe I've misunderstood the point of declaring a delegate parameter scope.
> 
> Take the following example:
> 
> void delegate(int) global_dg;
> 
> void foo(void delegate(int) dg)
> {
>    global_dg = dg;
> }
> 
> void foo2(scope void delegate(int) dg)
> {
>    dg(5);
> }
> 
> void bar(scope void delegate(int) dg)
> {
>    foo(dg); // should this compile?
>    foo2(dg); // should this compile?
> }
> 
> void baz()
> {
>    int y;
>    void dg(int x) { y += x; }
>    bar(&dg);
> }
> 
> Should bar's call to foo compile?

It compiles.

> If it does, then the benefit of having scope delegates is just a hint to the compiler that "I know what I'm doing".

Yes, seems like for now it's just a hint.  No checking is done.

The problem is, the declaration:

  scope var = ...;

means something completely different from

  void foo(scope void delegate() dg);
  foo(...);

The former defines a scoped instance of a class.  Ideally it should fail if used with any non-class type because it makes no sense with non-classes.

The latter defines a delegate in a non-escaping context.  Currently such definition is possible only as a parameter to a function call.

If delegate is defined in a non-escaping context, it gets a stack closure.  If it is defined as a scoped instance of a class... well, it makes no sense, so the scope is ignored and the delegate is created as usual, with a heap-allocated closure.

"Sergey Gromov" wrote
> Mon, 1 Dec 2008 14:10:27 -0500, Steven Schveighoffer wrote:
>
>> "Walter Bright" wrote
>>> 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.
>>
>> Maybe I've misunderstood the point of declaring a delegate parameter scope.
>>
>> Take the following example:
>>
>> void delegate(int) global_dg;
>>
>> void foo(void delegate(int) dg)
>> {
>>    global_dg = dg;
>> }
>>
>> void foo2(scope void delegate(int) dg)
>> {
>>    dg(5);
>> }
>>
>> void bar(scope void delegate(int) dg)
>> {
>>    foo(dg); // should this compile?
>>    foo2(dg); // should this compile?
>> }
>>
>> void baz()
>> {
>>    int y;
>>    void dg(int x) { y += x; }
>>    bar(&dg);
>> }
>>
>> Should bar's call to foo compile?
>
> It compiles.

I meant, should it compile in the final incarnation of this feature.

>> If it does, then the benefit of having
>> scope delegates is just a hint to the compiler that "I know what I'm
>> doing".
>
> Yes, seems like for now it's just a hint.  No checking is done.
>
> The problem is, the declaration:
>
>  scope var = ...;
>
> means something completely different from
>
>  void foo(scope void delegate() dg);
>  foo(...);
>
> The former defines a scoped instance of a class.  Ideally it should fail if used with any non-class type because it makes no sense with non-classes.

I was proposing to MAKE scope var = &dg mean what I said it should mean.  I am not talking about the current spec.

> The latter defines a delegate in a non-escaping context.  Currently such definition is possible only as a parameter to a function call.

Currently being the key word here ;)

> If delegate is defined in a non-escaping context, it gets a stack closure.  If it is defined as a scoped instance of a class... well, it makes no sense, so the scope is ignored and the delegate is created as usual, with a heap-allocated closure.

It makes sense.  A scope variable doesn't escape it's scope.  Why should this be limited to classes?  In fact, the scope delegate versus non-scope delegate is 100% analogous to scope classes versus non-scope classes.

My point in all this is Walter is saying it cannot be done, when in fact it can, and should be easy to determine, assuming that the eventual goal of this feature is to prevent scope delegate escapes.  Without knowing which delegates are scope and which are not is very important to escape analysis. Even partial escape analysis.  If the compiler can't determine that, then all this does is give a hint to the compiler, which isn't very useful at all, and seems half-ass in the face of all the other great features D2 is creating.

-Steve

I don't really consider this bug to be fixed in 1.037 and I have added comments explaining why. The bug has been marked as fixed though without any explanation as to why the shading mode (windows) and permissions (linux) are to be left as they are.

Spacen Jasset wrote:
> I don't really consider this bug to be fixed in 1.037 and I have added comments explaining why. The bug has been marked as fixed though without any explanation as to why the shading mode (windows) and permissions (linux) are to be left as they are.
> 

Tango also opens files for writing with shared reading disabled by default.  I'm not sure why, but maybe someone can remember the reason for it.

On Mon, 08 Dec 2008 18:35:32 +0300, torhu <no@spam.invalid> wrote:

> Spacen Jasset wrote:
>> I don't really consider this bug to be fixed in 1.037 and I have added comments explaining why. The bug has been marked as fixed though without any explanation as to why the shading mode (windows) and permissions (linux) are to be left as they are.
>>
>
> Tango also opens files for writing with shared reading disabled by default.  I'm not sure why, but maybe someone can remember the reason for it.

Yeah, just hit by this one :( (can't read program log until it is finished)

On Mon, 08 Dec 2008 18:35:32 +0300, torhu <no@spam.invalid> wrote:

> Spacen Jasset wrote:
>> I don't really consider this bug to be fixed in 1.037 and I have added comments explaining why. The bug has been marked as fixed though without any explanation as to why the shading mode (windows) and permissions (linux) are to be left as they are.
>>
>
> Tango also opens files for writing with shared reading disabled by default.  I'm not sure why, but maybe someone can remember the reason for it.

Yeah, just hit by this one :( (can't read program log until it is finished)

torhu Wrote:

> Tango also opens files for writing with shared reading disabled by default.  I'm not sure why, but maybe someone can remember the reason for it.

they just forgot? :)

On 2008-12-08 19:06:42 +0100, Kagamin <spam@here.lot> said:

> torhu Wrote:
> 
>> Tango also opens files for writing with shared reading disabled by
>> default.  I'm not sure why, but maybe someone can remember the reason
>> for it.
> 
> they just forgot? :)

consistency with windows as far as I know, so the program behaves the same on windows and unix.

Fawzi

On 2008-12-09 11:10:33 +0100, Fawzi Mohamed <fmohamed@mac.com> said:

> On 2008-12-08 19:06:42 +0100, Kagamin <spam@here.lot> said:
> 
>> torhu Wrote:
>> 
>>> Tango also opens files for writing with shared reading disabled by
>>> default.  I'm not sure why, but maybe someone can remember the reason
>>> for it.
>> 
>> they just forgot? :)
> 
> consistency with windows as far as I know, so the program behaves the same on windows and unix.
> 
> Fawzi

Anyway you can try to file a ticket to change the default if you want...