In D2, what is the effect (if any) of 'scope' in the following situations?

  scope int a;

  struct B { ... }
  scope B b;

  scope int[] c;

  // According to the spec, 'in' is shorthand for 'const scope'.
  void foo(in char[] d) { ... }


Thanks,
-Lars

Lars T. Kyllingstad:
> In D2, what is the effect (if any) of 'scope' in the following situations?

I think, it's just sloppiness of the compiler. I have reported similar things in a bug report time ago, bug 3934. If the things you have found are missing in that bug report, you can add them.

Bye,
bearophile

Lars T. Kyllingstad wrote:
> In D2, what is the effect (if any) of 'scope' in the following situations?
> 
>   scope int a;

Nothing

> 
>   struct B { ... }
>   scope B b;

Nothing, B's destructor will be called even without scope.

> 
>   scope int[] c;

c gets deleted when the scope ends. this applies to classes as well.

> 
>   // According to the spec, 'in' is shorthand for 'const scope'.
>   void foo(in char[] d) { ... }

d is const (read only).
I've no idea why scope is mentioned, it's meaningless in the context
of function arguments.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

div0 wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Lars T. Kyllingstad wrote:
>> In D2, what is the effect (if any) of 'scope' in the following situations?
>>
>>   scope int a;
> 
> Nothing
> 
>>   struct B { ... }
>>   scope B b;
> 
> Nothing, B's destructor will be called even without scope.
> 
>>   scope int[] c;
> 
> c gets deleted when the scope ends. this applies to classes as well.
> 
>>   // According to the spec, 'in' is shorthand for 'const scope'.
>>   void foo(in char[] d) { ... }
> 
> d is const (read only).
> I've no idea why scope is mentioned, it's meaningless in the context
> of function arguments.

I think in one of the early, complicated versions of the const system, it meant something. Looks like this mention of it was accidentally left in the spec.

On Sun, 30 May 2010 08:15:50 +0200, Don wrote:

> div0 wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 
>> Lars T. Kyllingstad wrote:

[...]

>>>   // According to the spec, 'in' is shorthand for 'const scope'. void
>>>   foo(in char[] d) { ... }
>> 
>> d is const (read only).
>> I've no idea why scope is mentioned, it's meaningless in the context of
>> function arguments.
> 
> I think in one of the early, complicated versions of the const system, it meant something. Looks like this mention of it was accidentally left in the spec.

So in the context of function arguments, 'in' is just a synonym for 'const'?  It seems to me like it should be removed from the language, then.

-Lars

Lars T. Kyllingstad:
> So in the context of function arguments, 'in' is just a synonym for 'const'?  It seems to me like it should be removed from the language, then.

http://d.puremagic.com/issues/show_bug.cgi?id=3943.

Bye,
bearophile

div0 wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Lars T. Kyllingstad wrote:
>> In D2, what is the effect (if any) of 'scope' in the following situations?
>>
>>   scope int a;
> 
> Nothing

http://www.digitalmars.com/d/2.0/attribute.html#scope
"This means that the destructor for an object is automatically called when the reference to it goes out of scope."
So there are two ways to interpret this:

- primitive types don't have destructors, so it shouldn't compile

- the destructor of a primitive type is nop, so the reason it has no effect at the moment is
http://d.puremagic.com/issues/show_bug.cgi?id=2483

>>   struct B { ... }
>>   scope B b;
> 
> Nothing, B's destructor will be called even without scope.
> 
>>   scope int[] c;
> 
> c gets deleted when the scope ends. this applies to classes as well.
<snip>

What gets deleted - the array or the individual objects?

Stewart.

Stewart Gordon wrote:
> div0 wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Lars T. Kyllingstad wrote:
>>> In D2, what is the effect (if any) of 'scope' in the following
>>> situations?
>>>
>>>   scope int a;
>>
>> Nothing
> 
> http://www.digitalmars.com/d/2.0/attribute.html#scope
> "This means that the destructor for an object is automatically called
> when the reference to it goes out of scope."
> So there are two ways to interpret this:
> 
> - primitive types don't have destructors, so it shouldn't compile
> 
> - the destructor of a primitive type is nop,

Meh. I don't really care either which way, though perhaps for the sake of writing template code it should continue to be allowed as a nop.

> so the reason it has no effect at the moment is http://d.puremagic.com/issues/show_bug.cgi?id=2483

No, that bug is completely different.
None of Lars example code involved assigning to a scope var after it's
declaration. We've discussed this before; allowing assignment to a scope
variable raise questions about which object should actually be deleted.

> 
>>>   struct B { ... }
>>>   scope B b;
>>
>> Nothing, B's destructor will be called even without scope.
>>
>>>   scope int[] c;
>>
>> c gets deleted when the scope ends. this applies to classes as well.
> <snip>
> 
> What gets deleted - the array or the individual objects?
> 
> Stewart.

Just the array. There maybe references to those objects elsewhere. Though if the compiler can do escape analysis and prove all the objects are dead, then they should be deleted at end of scope as well.

- --
My enormous talent is exceeded only by my outrageous laziness.
http://www.ssTk.co.uk

div0 wrote:
<snip>
> No, that bug is completely different.
> None of Lars example code involved assigning to a scope var after it's
> declaration. We've discussed this before; allowing assignment to a scope
> variable raise questions about which object should actually be deleted.

True, but you stated before that scope on a primitive type does _nothing_ effect, so I was just pointing out that by spec that isn't literally the case.

>>>>   struct B { ... }
>>>>   scope B b;
>>> Nothing, B's destructor will be called even without scope.
>>>
>>>>   scope int[] c;
>>> c gets deleted when the scope ends. this applies to classes as well.
>> <snip>
>>
>> What gets deleted - the array or the individual objects?
>>
>> Stewart.
> 
> Just the array. There maybe references to those objects elsewhere.
> Though if the compiler can do escape analysis and prove all the objects
> are dead, then they should be deleted at end of scope as well.

But you might also want to create an array of RAII objects.

At the moment, you can't have an array of a scope class, and if you want an array of RAII objects you have to declare each individually and then put them into the array (meaning there can only be a fixed number of them).

Stewart.