Thread overview
List of all permitted operations on scope function parameters.
Apr 15
Loara
Apr 16
Loara
Apr 17
Loara
Apr 17
user1234
Apr 17
Loara
April 15

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.

April 15

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

>

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.

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

April 16

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

>

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

>

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.

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

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).

April 17

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

>

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

>

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.

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

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

April 17

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

>

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

>

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

>

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.

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

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

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;
    }
}
>

/tmp/temp_7F010929C2D0.d:8:11: Error: scope variable b assigned to a with longer lifetime

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

April 17

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

>

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

>

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

>

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

>

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.

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

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

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;
    }
}
>

/tmp/temp_7F010929C2D0.d:8:11: Error: scope variable b assigned to a with longer lifetime

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

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.