On 12/05/2025 9:24 PM, Manu wrote:
> On Mon, 12 May 2025 at 03:55, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>> wrote:
> 
>     On 5/10/2025 9:07 PM, Manu wrote:
>      > I tested that and it didn't work for me. Maybe my test was faulty
>     somehow since
>      > I was working through numerous combinations, I'll try it again...
> 
> 
>     I just tried it again, with the same result.
> 
> 
> __gshared int* g;
> void test(scope int* x)
> {
>      g = x;
> }
> 
> I just compiled this with -dip1000, and it compiles... This looks like an escape to me! What have I misunderstood here?

Both ``__gshared`` and ``shared`` is disallowed by ``@safe`` (direct assign/access), and ``@safe`` has to be in use.

``-preview=dip1000``

```d
int* g;
void test(scope int* x) @safe {
    g = x; // Error: scope variable `x` assigned to global variable `g`
}
```

On Monday, 12 May 2025 at 09:24:13 UTC, Manu wrote:
> On Mon, 12 May 2025 at 03:55, Walter Bright via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>
>> On 5/10/2025 9:07 PM, Manu wrote:
>> > I tested that and it didn't work for me. Maybe my test was faulty
>> somehow since
>> > I was working through numerous combinations, I'll try it again...
>>
>>
>> I just tried it again, with the same result.
>>
>
> __gshared int* g;
> void test(scope int* x)
> {
>     g = x;
> }
>
> I just compiled this with -dip1000, and it compiles... This looks like an escape to me! What have I misunderstood here?

Have you @safe: on the top?

On Mon, 12 May 2025 at 19:41, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 12/05/2025 9:24 PM, Manu wrote:
> > On Mon, 12 May 2025 at 03:55, Walter Bright via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars-d@puremagic.com>>
> wrote:
> >
> >     On 5/10/2025 9:07 PM, Manu wrote:
> >      > I tested that and it didn't work for me. Maybe my test was faulty
> >     somehow since
> >      > I was working through numerous combinations, I'll try it again...
> >
> >
> >     I just tried it again, with the same result.
> >
> >
> > __gshared int* g;
> > void test(scope int* x)
> > {
> >      g = x;
> > }
> >
> > I just compiled this with -dip1000, and it compiles... This looks like an escape to me! What have I misunderstood here?
>
> Both ``__gshared`` and ``shared`` is disallowed by ``@safe`` (direct assign/access), and ``@safe`` has to be in use.
>
> ``-preview=dip1000``
>
> ```d
> int* g;
> void test(scope int* x) @safe {
>      g = x; // Error: scope variable `x` assigned to global variable `g`
> }
> ```
>
>
`scope` shouldn't depend on @safe, and Walter above said it depended only
on -dip1000.
So, if it only works with @safe, I repeat again; WHY? It's not only
redundant annotation, but it's also a ticking bomb waiting to explode... I
already commented on this.

On 12/05/2025 10:55 PM, Manu wrote:
> `scope` shouldn't depend on @safe, and Walter above said it depended only on -dip1000.
> So, if it only works with @safe, I repeat again; WHY? It's not only redundant annotation, but it's also a ticking bomb waiting to explode... I already commented on this.

@safe is the static analysis on a function that the compiler guarantees is memory safe.

@trusted is the escape hatch where you have to do something that the compiler cannot make guarantees for.

@system has no guarantees associated with it.

All scope says is that this variable will not escape this function.

It does not have any kind of ownership properties.

It is not redundant information, it does serve an important purpose in escape analysis.

When you see no attributes, think unknown escape behavior, it is not modeled. Not, this doesn't escape, or it escapes into an unknown location. These are all different things.

On Mon, 12 May 2025 at 21:10, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com> wrote:

> On 12/05/2025 10:55 PM, Manu wrote:
> > `scope` shouldn't depend on @safe, and Walter above said it depended
> > only on -dip1000.
> > So, if it only works with @safe, I repeat again; WHY? It's not only
> > redundant annotation, but it's also a ticking bomb waiting to explode...
> > I already commented on this.
>
> @safe is the static analysis on a function that the compiler guarantees is memory safe.
>

`scope` has nothing to do with @safe. I want to prohibit the callee retaining the argument; simple as that.

@trusted is the escape hatch where you have to do something that the
> compiler cannot make guarantees for.
>

This has nothing to do with @safe.

@system has no guarantees associated with it.
>
> All scope says is that this variable will not escape this function.


Exactly. Nothing to do with @safe.

It does not have any kind of ownership properties.
>

Correct.

It is not redundant information, it does serve an important purpose in
> escape analysis.
>

Incorrect.

When you see no attributes, think unknown escape behavior, it is not
> modeled. Not, this doesn't escape, or it escapes into an unknown location. These are all different things.
>

Okay, I'll repeat for the 3rd time or so; when `scope` is annotated to an argument, it MUST have effect, otherwise an escape related crash is inevitable that the user intended to prevent, and when they start debugging and trying to track down the issue; they will see the `scope` annotation, assume it's not that, then move on to continue looking in the wrong place for their issue.

`scope` has nothing to do with @safe, and it MUST work in its own right, otherwise the code is lying to the author, and it's an effective liability.

On 12/05/2025 11:16 PM, Manu wrote:
> On Mon, 12 May 2025 at 21:10, Richard (Rikki) Andrew Cattermole via Digitalmars-d <digitalmars-d@puremagic.com <mailto:digitalmars- d@puremagic.com>> wrote:
> 
>     On 12/05/2025 10:55 PM, Manu wrote:
>      > `scope` shouldn't depend on @safe, and Walter above said it depended
>      > only on -dip1000.
>      > So, if it only works with @safe, I repeat again; WHY? It's not only
>      > redundant annotation, but it's also a ticking bomb waiting to
>     explode...
>      > I already commented on this.
> 
>     @safe is the static analysis on a function that the compiler guarantees
>     is memory safe.
> 
> 
> `scope` has nothing to do with @safe. I want to prohibit the callee retaining the argument; simple as that.

Use @safe.

@system and @trusted simply do not, and will not have these guarantees.

There must be an escape hatch, and those are what D has it defined as.

>     @trusted is the escape hatch where you have to do something that the
>     compiler cannot make guarantees for.
> 
> 
> This has nothing to do with @safe.
> 
>     @system has no guarantees associated with it.
> 
>     All scope says is that this variable will not escape this function.
> 
> 
> Exactly. Nothing to do with @safe.

It has everything to do with @safe, that is where the mechanical checks exist.

You do not need the escape set (``scope``), if you do not have the mechanical checks, and where you have an escape hatch (``@trusted`` and ``@system``), these are intentionally not turned on.

>     It is not redundant information, it does serve an important purpose in
>     escape analysis.
> 
> 
> Incorrect.

I have spent the last couple of years studying escape analysis, along with what attributes mean when they are missing specifically due to DIP1000's ``return scope`` and ``scope return`` mess.

Not only this, but I know enough of the DFA theory including what clang-analyzer does for frontend analysis to have been implementing that in dmd.

It is not redundant, this is a defining trait of how this stuff works.

>     When you see no attributes, think unknown escape behavior, it is not
>     modeled. Not, this doesn't escape, or it escapes into an unknown
>     location. These are all different things.
> 
> 
> Okay, I'll repeat for the 3rd time or so; when `scope` is annotated to an argument, it MUST have effect, otherwise an escape related crash is inevitable that the user intended to prevent, and when they start debugging and trying to track down the issue; they will see the `scope` annotation, assume it's not that, then move on to continue looking in the wrong place for their issue.

Okay agreed.

We should disallow it for @system functions, they do not interact with any static analysis in any way.

> `scope` has nothing to do with @safe, and it MUST work in its own right, otherwise the code is lying to the author, and it's an effective liability.

No, it is auxiliary lint level annotation on variables.

It is not a type qualifier and is not checked in the type system itself.

Data flow analysis in a frontend is lint level, it works after the rest of compilation has been completed. It adds information, but it doesn't mess with the type system itself, if it adds information it wants to check within the type system, DFA is responsible for doing the checks, not the type system. The distinction matters.

On 5/12/25 13:52, Richard (Rikki) Andrew Cattermole wrote:
> 
> It has everything to do with @safe, that is where the mechanical checks exist.
> 
> You do not need the escape set (``scope``), if you do not have the mechanical checks, and where you have an escape hatch (``@trusted`` and ``@system``), these are intentionally not turned on.

Even in `@system` code you cannot assign an `int` to an `int*`, you have to use an explicit cast. I don't think it is true that just because `@system` does not give you memory safety guarantees it will therefore be expected that features do not work at all.

This is a design decision, and I think Manu's and Walter's expectations are more reasonable than what the compiler actually does.

On 13/05/2025 12:34 AM, Timon Gehr wrote:
> On 5/12/25 13:52, Richard (Rikki) Andrew Cattermole wrote:
>>
>> It has everything to do with @safe, that is where the mechanical checks exist.
>>
>> You do not need the escape set (``scope``), if you do not have the mechanical checks, and where you have an escape hatch (``@trusted`` and ``@system``), these are intentionally not turned on.
> 
> Even in `@system` code you cannot assign an `int` to an `int*`, you have to use an explicit cast. I don't think it is true that just because `@system` does not give you memory safety guarantees it will therefore be expected that features do not work at all.
> 
> This is a design decision, and I think Manu's and Walter's expectations are more reasonable than what the compiler actually does.

Right, perhaps if it was a different design, say unsafe blocks I'd agree with what Manu is saying.

Unfortunately the current design has a valid set of tradeoffs.

And from experience you must have some sort of escape hatch, and that is ``@trusted`` and ``@system`` currently, enforcing ``scope`` there would make it unusable.

On 5/11/25 20:03, Walter Bright wrote:
> On 5/11/2025 4:32 AM, Timon Gehr wrote:
>> Well, it's common enough to need type system support.
> 
> That's not necessarily true.

You had claimed it is not a severe limitation. It's common enough to need type system support to not be severely limited.

> You can do everything in C that D does, it's just less convenient.
> ...

Severely so.

> 
>> Support for multiple indirections is also important. Rust actually provides both of these.
> 
> There are other ways to do that. Multiple indirections can be handled by using structs and then only allowing access to structs through member function interfaces.
> ...

Well, safe dynamic arrays can be handled by creating a custom struct and accessing it with API functions that perform bounds checks. Yet C programmers rarely do this.

> 
>>> It's a minor inconvenience that can be refactored away.
>> In general you'll have to resort to `@system` code,
> 
> While you can always do it with @system code, I'm not convinced some refactoring won't work. It's not a disaster to use @system code now and then.
> ...

The best you can usually do is to manually move safety checks to runtime. The point of a type system in this case is to avoid that overhead and to give assurances before the program actually runs or even ships to users.

> 
>> and it will stand in the way of other refactorings you may want to do.
> 
> You've got to do a lot of refactoring to make Rust code work anyway.
> ...

The inflexibility of Rust is indeed one of the main points of critique that is directed against it.

On 5/12/25 14:41, Richard (Rikki) Andrew Cattermole wrote:
> On 13/05/2025 12:34 AM, Timon Gehr wrote:
>> On 5/12/25 13:52, Richard (Rikki) Andrew Cattermole wrote:
>>>
>>> It has everything to do with @safe, that is where the mechanical checks exist.
>>>
>>> You do not need the escape set (``scope``), if you do not have the mechanical checks, and where you have an escape hatch (``@trusted`` and ``@system``), these are intentionally not turned on.
>>
>> Even in `@system` code you cannot assign an `int` to an `int*`, you have to use an explicit cast. I don't think it is true that just because `@system` does not give you memory safety guarantees it will therefore be expected that features do not work at all.
>>
>> This is a design decision, and I think Manu's and Walter's expectations are more reasonable than what the compiler actually does.
> 
> Right, perhaps if it was a different design, say unsafe blocks I'd agree with what Manu is saying.
> 
> Unfortunately the current design has a valid set of tradeoffs.
> 
> And from experience you must have some sort of escape hatch, and that is ``@trusted`` and ``@system`` currently, enforcing ``scope`` there would make it unusable.
> 

There can be another way to circumvent `scope` checks that is itself considered `@system`. As Walter and Manu have demonstrated, it is not even consistent. Some checks are still active, others are not.