Documentation page https://dlang.org/spec/function.html#scope-parameters about scope function parameters says simply that a scoped parameter "can't escape that function's scope". This concept can be very tricky with some non-trivial algebra of struct's members and pointers, so I think it's better to provide a general algorithm to state if an expression/statement involving one or more scope function parameters is valid or not.

On Friday, 15 April 2022 at 21:57:28 UTC, Loara wrote:

scope and return are both my nightmare. scope(exit) // blah blah, no problem and even return result It's okay...

But when I come across these elsewhere, it's scary. Especially in function parameters!

@SDB79

On Friday, 15 April 2022 at 23:17:26 UTC, Salih Dincer wrote:

Exactly, but i think that if correctly defined scope can be a very powerful tool, in particular when dealing with shared: we could define a safe critical block (or reuse synchronize blocks) guarded by mutex in order to automatically cast the selected shared variables as scope (via scope ref parameters).

On Friday, 15 April 2022 at 23:17:26 UTC, Salih Dincer wrote:

https://github.com/Loara/Rethink_scope_in_D/blob/main/README.md

On Sunday, 17 April 2022 at 08:57:40 UTC, Loara wrote:

The first example you give is actually well rejected but only in @safe code:

int* stack_allocate(size_t) @safe;

void test() @safe
{
    scope int *a;
    {
        scope int *b = stack_allocate(1);
        a = b;
    }
}

it's not mentioned in the specs for @safe however.

On Sunday, 17 April 2022 at 12:35:25 UTC, user1234 wrote:

int* stack_allocate(size_t) @safe;

void test() @safe
{
    scope int *a;
    {
        scope int *b = stack_allocate(1);
        a = b;
    }
}

It's not a compilation error, it's an incomplete documentation issue since if we follows only the official documentation this should compile, and it'll compile if we remove the innermost block (as explained in the next example). Making scope operation not transitive let it a cumbersome tool that force programmers to use a lot of casts.

Notice also that the preceding code will compile if we translate it to

import std.stdio;

extern int * stack_allocate() @trusted;

    int main() @safe{
        scope int *a;
        {
            scope int **b = new int *();
            *b = stack_allocate();
            a = *b;
        }
        return 0;
    }

because the scope storage class is not transitive.

The real question at this point is: we want to make scope only a tool in order to allow stack allocation, or we want to use it in order to avoid any indirection inside it to escape its scope (for example when we want to manage a shared object inside a synchronized block)?

I don't see at this moment any clear objective behind the scope attribute, any well defined purpose.

In the next articles I'll explain better the idea of a scoped block as a way to statically control which indirections escapes and which not.