On 23/06/2025 3:08 AM, Neto wrote:
> this give the error:
> 
> ```d
> @safe:
> int *gp2;
> int g(scope int *p)
> {
>      gp2 = p;
>      return -1;
> }
> ```
> 
>>  Error: scope variable p assigned to non-scope gp2
> 
> but this one doesn't give any error:
> 
> ```d
> @safe:
> 
> int gg;
> 
> int f(scope int c)
> {
>      int k = c;
>      gg = c;
>      return k * 8;
> }
> ```
> 
> this is why `c` is a "simple variable" can be allocated onto stack and copied without any issue? if not, why exactly this one doesn't give error?

An int is a basic type, by itself it can live in a register and does not have a unique memory address.

The location its in on the stack is irrelevant unless you take a pointer to it. In essence its a implementation detail.

It'll move between locations freely, this is why scope doesn't affect it. Because there is no resource to protect.

On Sunday, 22 June 2025 at 15:53:45 UTC, Richard (Rikki) Andrew Cattermole wrote:
> An int is a basic type, by itself it can live in a register and does not have a unique memory address.
>
> The location its in on the stack is irrelevant unless you take a pointer to it. In essence its a implementation detail.
>
> It'll move between locations freely, this is why scope doesn't affect it. Because there is no resource to protect.

I think scope should not be allowed on basic types, as it has no effect and is only confusing.
I know, it would be needed to enable generic programming, but I find a function that can take both an int and an int* suspect anyway - this is kind of too generic for my taste.

On Monday, June 23, 2025 8:53:18 AM Mountain Daylight Time Dennis via Digitalmars-d-learn wrote:
> On Monday, 23 June 2025 at 10:37:58 UTC, Dom DiSc wrote:
> > I know, it would be needed to enable generic programming, but I find a function that can take both an int and an int* suspect anyway - this is kind of too generic for my taste.
>
> Would you say `HashMap!(Key, Value).opIndex(scope Key)` is too
> generic, and that `int[string]` and `int[int]` should have
> separate implementation code?
>
> I'm not against the compiler giving errors on no-op single attributes, but in some cases this can be complex for dmd's current implementation. For example, `pure T x;` has no effect unless T turns out to be a function type, which requires extra checks after `T` has been resolved. `scope` was internally removed from parameters by the compiler when the type had no pointers, but this caused forward reference errors:
>
> https://issues.dlang.org/show_bug.cgi?id=21667
>
> Giving an error on no-op `scope` attributes has the exact same problem.

There's also the issue of templated code. If an attribute is desirable in the cases where it works, and it's fine for it to be ignored in the cases where it doesn't apply, then that means that you can have code such as

    scope T foo;

or

    pure T foo;

without having to worry about whether the attribute works with a particular T.

On the other hand, if it's an error for the attribute to be applied, then the code will need to do something like use a static if to apply the attribute, e.g.

    static if(isPointer!T || is(T == class) ||
              isDynamicArray!T || isAssociativeArray!T)
    {
        scope T foo;
    }
    else
        T foo;

and of course, if you get the check wrong, then the attribute won't be applied properly.

So, if the attribute is no longer ignored, that will create certain classes of problems that we don't currently have. It's a different set of problems from the current situation, and it's debatable as to which situation is better or worse, but it's nowhere near as straightforward as it first seems.

- Jonathan M Davis