(More correctly, "scope storage class".)

  https://dlang.org/spec/function.html#Parameter

still says

  scope: references in the parameter cannot be escaped
         (e.g. assigned to a global variable). Ignored for
         parameters with no references

However, it doesn't behave that way. For example, my example here currently is a lie because there is no compilation error with 2.073.2:


http://ddili.org/ders/d.en/function_parameters.html#ix_function_parameters.scope

What's the truth? How would you change the text there?

Thank you,
Ali

On Tuesday, March 28, 2017 22:15:33 Ali Çehreli via Digitalmars-d-learn wrote:
> (More correctly, "scope storage class".)
>
>    https://dlang.org/spec/function.html#Parameter
>
> still says
>
>    scope: references in the parameter cannot be escaped
>           (e.g. assigned to a global variable). Ignored for
>           parameters with no references
>
> However, it doesn't behave that way. For example, my example here currently is a lie because there is no compilation error with 2.073.2:
>
>
> http://ddili.org/ders/d.en/function_parameters.html#ix_function_parameters .scope
>
> What's the truth? How would you change the text there?
>
> Thank you,
> Ali

Not sure when that was changed, since that's not what the spec used to say on scope. IIRC, it used to be that it did not say anything about references and was _very_ vague. But unless something major has changed, _all_ scoped does at this point is make it so that a delegate will not allocate a closure. I'm not sure that it's even properly checked for escaping (though it may be). But scoped has zero effect on other types.

Now, I believe that Walter has been working on stuff that would change that, but I don't think that any of that has made it in yet except maybe with a compiler switch intended to separate out the changes until they're ready.

- Jonathan M Davis

On Wednesday, 29 March 2017 at 05:15:33 UTC, Ali Çehreli wrote:
> (More correctly, "scope storage class".)
>
>   https://dlang.org/spec/function.html#Parameter
>
> still says
>
>   scope: references in the parameter cannot be escaped
>          (e.g. assigned to a global variable). Ignored for
>          parameters with no references
>
> However, it doesn't behave that way. For example, my example here currently is a lie because there is no compilation error with 2.073.2:
>
>
> http://ddili.org/ders/d.en/function_parameters.html#ix_function_parameters.scope
>
> What's the truth? How would you change the text there?
>
> Thank you,
> Ali

The truth is that almost non of the scope checks are on, unless you compile with -dip1000:
$ source ~/dlang/dmd-2.073.2/activate
$ dmd ddili_scope_test1.d
$ echo $?
0
$ dmd -dip1000 ddili_scope_test1.d
ddili_scope_test1.d(5): Error: scope variable parameter may not be returned

Now that's one error, out of two expected, so what's going on here? As DIP1000 mentions (https://github.com/dlang/DIPs/blob/master/DIPs/DIP1000.md#safe):

> Errors for scope violations are only reported in @safe code.

So if when I changed the code to:

int[] globalSlice;

int[] foo(scope int[] parameter) @safe {
    globalSlice = parameter;    // ← compilation ERROR
    return parameter;           // ← compilation ERROR
}

void main() {
    int[] slice = [ 10, 20 ];
    int[] result = foo(slice);
}

I got:
$ dmd -dip1000 ddili_scope_test1.d
ddili_scope_test1.d(4): Error: scope variable parameter assigned to non-scope globalSlice
ddili_scope_test1.d(5): Error: scope variable parameter may not be returned

Just as expected.

On Wednesday, 29 March 2017 at 05:15:33 UTC, Ali Çehreli wrote:
> [..] How would you change the text there?

scope: references in the parameter cannot be escaped (e.g. assigned
       to a global variable) in @safe code when compiled with -dip1000.
       Ignored for parameters with no references.

On Wednesday, 29 March 2017 at 05:15:33 UTC, Ali Çehreli wrote:
>   scope: references in the parameter cannot be escaped
>          (e.g. assigned to a global variable). Ignored for
>          parameters with no references
>
> However, it doesn't behave that way. For example, my example here currently is a lie because there is no compilation error with 2.073.2:

If you break the rules, even if the compiler doesn't actually catch it, you are still writing illegal code and subject to runtime undefined behavior and/or compilation errors in future versions.

The compiler DOES use the scope attribute to optimize out heap allocations in some cases now, which means if you use in improperly you are liable for memory corruption.

So maybe it should say "must not" instead of "cannot" since you CAN, it is just broken if you do.