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

--- Comment #1 from FeepingCreature <default_357-line@yahoo.de> ---
Different instance of probably the same bug:

immutable struct Struct { }

struct Wrapper {
    void foo(U)(inout(U)) inout {
        // U is inferred as 'struct Struct', not 'immutable struct Struct'.
        // evidence:
        pragma(msg, isMutable!Struct.stringof ~ " - " ~ isMutable!U.stringof);
        static assert(is(U == Struct));
    }
}

Wrapper().foo(Struct());

--

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

Mario Kroeplin <kroeplin.d@googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |industry
                 CC|                            |kroeplin.d@googlemail.com

--

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

--- Comment #2 from FeepingCreature <default_357-line@yahoo.de> ---
Just ran into this issue again.

--

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

Paul Backus <snarwin+bugzilla@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |snarwin+bugzilla@gmail.com

--- Comment #3 from Paul Backus <snarwin+bugzilla@gmail.com> ---
Worth noting that even when immutable is stripped from the struct type itself, it still applies to the struct's members:

---
immutable struct S { int n; }
static if (is(S : immutable U, U))
{
    static assert(!is(U == immutable));
    static assert(is(typeof(U.n) == immutable));
}
---

--

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

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl
           Hardware|x86_64                      |All
                 OS|Linux                       |All

--- Comment #4 from Dennis <dkorpel@live.nl> ---
I don't think structs can have an 'inherent constness attribute'. The spec says:

https://dlang.org/spec/struct.html#const-struct

> A struct declaration can have a storage class of const, immutable or shared. It has an equivalent effect as declaring each member of the struct as const, immutable or shared.

So these structs are supposed to be treated the same:
```
immutable struct S0 { int n; }

struct S1 { immutable int n; }
```

Now note that even for S1, `is(S1 == immutable(S1))` does not hold.
I think the real issue is this:
```
pragma(msg, S0); // immutable(S0)
pragma(msg, S1); // S1
```
Referring to `S0` by name results in an `immutable(S0)` type instead of just
`S0` with immutable members.

--

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

--- Comment #5 from Dennis <dkorpel@live.nl> ---
Looking at https://github.com/dlang/dmd/pull/6958 and https://github.com/dlang/dmd/pull/13312, it seems like intended behavior.

--

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

--- Comment #6 from FeepingCreature <default_357-line@yahoo.de> ---
Well... it's ... still bad. (As well as spec-violating.) It means that there's straight up no way in the language to detect any difference between immutable struct S {} ... S and struct S { } ... immutable S.

The idea is that the constness attached to the type gives a hint as to how that type should be used. For instance with template functions that return Nullable, I would expect the first to return Nullable!(immutable S), ie. Nullable!S, and the second immutable Nullable!S. This is, at the moment, impossible due to this bug.

--

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

--- Comment #7 from Paul Backus <snarwin+bugzilla@gmail.com> ---
D's type system currently guarantees that for all qualified types Q(T), there exists the corresponding unqualified type T. Introducing special-case exceptions to this guarantee is likely to break at least as much code as it fixes (try `git grep 'Unqual!'` in Phobos to get a rough idea).

IMO if one wants to hint to users that a type should be used with a particular qualifier by default, a better way (that does not require weird corner cases in the type system) is to use a public alias to a qualified version of a private type.

--- lib.d
module lib;

private struct StructImpl { }
alias Struct = immutable(StructImpl);

--- app.d
import lib;

Struct s;
static assert(is(typeof(s) == immutable));
---

--

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

--- Comment #8 from FeepingCreature <default_357-line@yahoo.de> ---
> D's type system currently guarantees that for all qualified types Q(T), there exists the corresponding unqualified type T.

I disagree with this claim, specifically because `immutable struct S` exists. I don't see where D makes the claim that this is the case. `Unqual` says that it strips type qualifiers. But `immutable struct` is not actually a qualifier, it's an "immutable declaration." This is currently, apparently, implemented as an implicit qualifier, which is what this bug is about, and at any rate is not what the spec says.

What's the point of having unqualified types anyway? It's not the same as a mutable value conversion of the type regardless. (That would require headmutable.) So since it can't be used to make "a mutable field of T", I don't see what this gives you.

--

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

--- Comment #9 from Dennis <dkorpel@live.nl> ---
(In reply to FeepingCreature from comment #8)
> I disagree with this claim, specifically because `immutable struct S` exists. I don't see where D makes the claim that this is the case.

D didn't make the claim, Paul made the claim. It follows from how immutable is defined as something that modifies a type, see for example name mangling:

https://dlang.org/spec/abi.html#type_mangling

The compiler uses that for type identity. Also see how Type Qualifiers are implemented as a field in the top level `Type` class:

https://github.com/dlang/dmd/blob/c4cea697e8658f103a69967587e75dd130506304/src/dmd/mtype.d#L334

> But `immutable struct` is not actually
> a qualifier, it's an "immutable declaration." This is currently, apparently,
> implemented as an implicit qualifier, which is what this bug is about

Do you want to invent a new `immutable struct` concept, with its own mangling? Because I prefer not to complicate the type system, so I'm looking for a solution without special cases.

> and at any rate is not what the spec says.

I can clarify the spec, but I don't think that's what you're after.

--