in / out for C++ programmers

[Jonathan M Davis]

On Saturday, March 24, 2012 00:02:58 Ali Çehreli wrote:
> On 03/23/2012 11:50 PM, Jonathan M Davis wrote:
>  > On Friday, March 23, 2012 23:37:27 Ali Çehreli wrote:
>  >> 'in' is the same as 'const scope'. const part is easy to understand
>  >> but
>  >> I don't know what 'scope' does. I could not understand what the spec
>  >> means with "references in the parameter cannot be escaped (e.g.
>  >> assigned
>  >> 
>  >> to a global variable)" for scope:
>  >>     http://dlang.org/function.html
>  > 
>  > You mean that you don't understand what it means for a reference to
> 
> escape a
> 
>  > function?
> 
> No. I've known that for decades now. I don't understand it because I've
> tried what I've understood about scope in code examples and could not
> see any difference.
> 
> Also, I don't understand the semantics of it. For example, 'const' is
> welcoming: it says "I accept mutable and immutable references as
> parameters." (Because it is a guarantee that it will not modify.)
> 'immutable' is restricting: "I accept only immutable references."
> 
> What is 'scope' on a parameter? Is that a guarantee or a requirement on
> the argument?
> 
>  > In the case of scope, it means that what you pass in cannot be
> 
> assigned to a
> 
>  > global or static variable, and it cannot be returned from that
> 
> function. So,
> 
>  > for instance.
>  > 
>  > int[] foo(const int[] a)
>  > {
>  > 
>  >      ...
>  > 
>  > }
>  > 
>  > could not assign a to a global or static variable and cannot return it.
> 
> Yet this compiles:
> 
> int[] g;
> 
> int[] foo(scope int[] slice)
> {
>      g = slice;
>      return slice;
> }
> 
> void main()
> {
>      int[] slice;
>      int[] result = foo(slice);
> }
> 
> The funny thing is, what does function have to do the scope of a
> parameter that is passed to it? Since it's an argument passed from the
> outside it may be scoped or dynamic.
> 
> And that's why I don't understand it. :) I suspect scope is a remnant
> from the D1 days. (?)

The point of scope is to guarantee that no references to the argument passed 
in can escape the function. The variable passed in is irrelevant aside from 
whether it's a reference type (or pointer) or not. Now, there's every 
possibility (guarantee even, given your example) that scope is buggy. But as 
I understand it (and the spec seems to agree), the whole point of scope is 
to make it illegal for any argument passed to that parameter to escape the 
function it's being passed to. So, it restricts what the callee can do, but 
it doesn't restrict the caller.

>  > This
>  > can allow some additional optimizations as well as improve safety in
>  > some
>  > cases. For instance, if you pass
>  > 
>  > int[5] b;
>  > 
>  > to foo, then you know that no slice of that static array will escape,
> 
> since
> 
>  > something like
>  > 
>  > int[] bar()
>  > {
>  > 
>  >      int[5] c;
>  >      return c;
>  > 
>  > }
>  > 
>  > is just as bad as the case with&a. I believe that scope is used
>  > primarily
>  > with delegates however (particularly, since you often _want_ to be
> 
> able to
> 
>  > return a slice of an array passed to a function).
> 
> Fine, delegates... Is that a guarantee or a requirement in that context?

If the parameter that a delaget is being passed to is marked as scope, then 
it's supposed to be illegal for any references to it or its context to 
escape the function it's being passed to, which makes it possible for the 
compiler to avoid putting the delegate's context on the heap. That is a 
guarantee, and if it's not true, then the compiler is buggy. What I don't 
know is if the language guarantees that the compiler will do the 
optimization of not putting the delegate's context on the heap if it's 
passed to a scope parameter.

- Jonathan M Davis