[Issue 20670] immutable template specialization pattern matches immutable struct, strips immutable

[d-bugmail at puremagic.com]

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

--- Comment #11 from FeepingCreature <default_357-line at yahoo.de> ---
The problem is that it seems like Unqual has conflicting purposes - and this
is, I think, ultimately about Unqual; about the ability to take a type - any
type - and gain a mutable version.

The problem is that immutable, on one hand, says "it acts like every field has
been marked immutable." But the ability to mark a field immutable is already
enough to completely obsolete Unqual as a concept, since a declaration of
Unqual!T will not be a mutable value. Okay, so from this we take that it's just
the case that we have mutable types, and immutable types, and Unqual is a
specialty tool that's useless in the general case. (Hence our own
librebindable.) But then the ability to strip immutable from a type is a
problem. Because now you have to differentiate between "a type marked as
immutable" and "a type declaration marked as immutable". Because, since you've
already gained, necessarily, the ability to deal with types that cannot be
turned into mutable declarations by any means, there is no point to stripping
immutable from `immutable struct S` anymore. What does it buy you? The bubble
of types you can create a mutable declaration of gets a bit bigger. It still
doesn't cover an appreciable fraction of the D type landscape - including the
types you get if you *just replace immutable struct with the thing it says it's
a shortcut for!*

So from that basis, I'd drawn a distinction between 'immutable struct S' and
'struct S, immutable S' - as "in one case, the user may want to see a mutable
S, especially if used as an inner field in a constructed type; ie. we want to
move immutable as far outward as possible, as in `immutable Nullable!S`, and in
the other case, the user asserts that they never ever ever want to have to deal
with a mutable S for any reason."

Which makes sense, because that gives us pure value types, with working
invariants. Domain types, where we don't need to hide every field behind an
accessor - because *the only way* to set a field is via the constructor. As it
should be for domain types. So I've always thought that this was what
`immutable struct S` was for.

Because it's not like it's good for anything else.

--