I'm reading the Functions section of the D 2.0 documentation.
<http://www.digitalmars.com/d/2.0/function.html#parameters>.
Under Function Parameters, I read this:

	Parameter storage classes are in, out, ref, lazy, final, const, invariant, or scope.

then this:

	 The in storage class is equivalent to const scope.

But there is no explaination how scope affect things.

If I go find scope in the Attributes section
<http://www.digitalmars.com/d/2.0/attribute.html#scope>
I can find this which may be relevant to the case of a funciton parameter:

	For local declarations, scope implements the RAII (Resource Acquisition
	Is Initialization) protocol. This means that the destructor for an object is
	automatically called when the reference to it goes out of scope.

Is this really what it does? It sounds pretty silly that the function
destroys the object the caller has passed to it, so I guess it doesn't.

However, this part may apply when talking about function parameters:

	Assignment to a scope, other than initialization, is not allowed.
	Rationale: These restrictions may get relaxed in the future if a compelling
	reason to appears.

which would mean you just can't reassign a new value to a scope parameter
inside the function. That's just a guess of what it does, and to me it sounds
pointless and misnamed.

What is it in reality?

Anyhow, I think what scope does with a function parameters should be better
documented in the Functions section.

-- 
Michel Fortin
michel.fortin@michelf.com
http://michelf.com/

On Sun, 30 Mar 2008 07:08:57 -0400, Michel Fortin wrote:

> I'm reading the Functions section of the D 2.0 documentation. <http://www.digitalmars.com/d/2.0/function.html#parameters>. Under Function Parameters, I read this:
> 
> 	Parameter storage classes are in, out, ref, lazy, final, const,
> invariant, or scope.
> 
> then this:
> 
> 	 The in storage class is equivalent to const scope.

I'm pretty sure this is no longer used and is only there for backward compatability. In earlier editions of V2, it did have a usage but that was abandoned (I think).

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

On 30/03/2008, Michel Fortin <michel.fortin@michelf.com> wrote:
>  Anyhow, I think what scope does with a function parameters should be better
>  documented in the Functions section.

I don't see the point of documenting it better: Instead, just get rid of it.

"in" for function parameters is pointless.

Michel Fortin wrote:

> I'm reading the Functions section of the D 2.0 documentation. <http://www.digitalmars.com/d/2.0/function.html#parameters>. Under Function Parameters, I read this:
> 
> Parameter storage classes are in, out, ref, lazy, final, const, invariant, or scope.
> 
> then this:
> 
> The in storage class is equivalent to const scope.
> 
> But there is no explaination how scope affect things.
> 
> If I go find scope in the Attributes section
> <http://www.digitalmars.com/d/2.0/attribute.html#scope>
> I can find this which may be relevant to the case of a funciton parameter:
> 
> For local declarations, scope implements the RAII (Resource Acquisition Is Initialization) protocol. This means that the destructor for an object is automatically called when the reference to it goes out of scope.
> 
> Is this really what it does? It sounds pretty silly that the function destroys the object the caller has passed to it, so I guess it doesn't.
> 
> However, this part may apply when talking about function parameters:
> 
> Assignment to a scope, other than initialization, is not allowed. Rationale: These restrictions may get relaxed in the future if a compelling reason to appears.
> 
> which would mean you just can't reassign a new value to a scope parameter inside the function. That's just a guess of what it does, and to me it sounds pointless and misnamed.
> 
> What is it in reality?
> 
> Anyhow, I think what scope does with a function parameters should be better documented in the Functions section.
> 

My understanding is that the scope part of in hasn't been implemented yet :( My understanding is that the scope keyword should imply that the data is not available after the function call is over.  I personally like the idea of (non-invariant) data being able to become scope invariant (for the duration of a function call), but I haven't found anyone that shares my ideas.  To me, it's a logical extension of the const system...