https://issues.dlang.org/show_bug.cgi?id=24003

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl

--- Comment #1 from Dennis <dkorpel@live.nl> ---
(In reply to Bolpat from comment #0)
> Also, there’s some Schrödinger action going on with template type inference.

Yes, I'm all too aware of this.

It was decided at some point to make inferred `scope` and `return` not part of the type mangle, so that there wouldn't be link errors between phobos compiled with dip1000 and user code without it.

However, the compiler uses the mangle internally as the identity of a type. So if two types have the same mangled name, they are considered equal.

I tried undoing this, but of course, that breaks everything, so it's going to be hard to untangle the mess.

--

https://issues.dlang.org/show_bug.cgi?id=24003

--- Comment #2 from Dlang Bot <dlang-bot@dlang.rocks> ---
@dkorpel created dlang/dmd pull request #15333 "Issue 24003 - mangle inferred return/scope attributes in parameters" mentioning this issue:

- Issue 24003 - mangle inferred return/scope attributes in parameters

https://github.com/dlang/dmd/pull/15333

--

https://issues.dlang.org/show_bug.cgi?id=24003

Ate Eskola <Ajieskola@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Ajieskola@gmail.com

--- Comment #3 from Ate Eskola <Ajieskola@gmail.com> ---
I think this is same as what I was just about to report:

```d
auto nullPtr(int*) => (int*).init;

@safe unittest
{   int local;
    // compiles (with -preview=dip1000), because the parameter is correctly
inferred as scope
    auto nullP = nullPtr(&local);
}

// Yet this says AliasSeq!().
// Should say AliasSeq!"scope".
pragma(msg, __traits(getParameterStorageClasses, nullPtr, 0));
```

I was solving https://issues.dlang.org/show_bug.cgi?id=23300, but this bug is blocking me. Since `scope` inference is limited, `std.array.array` needs to manually introspect whether `.front` / `.opApply` / element copy of the source range are `scope`. With this bug, it only works in the rare few cases where `scope` is manually specified.

I have tried working around it by testing whether a call passing a `scope` argument compiles, but no joy. DIP1000 checks are only done in safe code, and trying to cast a `@system` function to a `@trusted` one to make the check work, without changing the function type in any other way or losing the `scope` inference, was just too difficult for me - probably impossible.

--

https://issues.dlang.org/show_bug.cgi?id=24003

Ate Eskola <Ajieskola@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |23300


Referenced Issues:

https://issues.dlang.org/show_bug.cgi?id=23300
[Issue 23300] std.array : array wrongly propagates scopeness of source
--