Phobos' traits.d's Unqual! template (needed for several of its other templates) does not handle arrays well:
writeln(Unqual!(const(int[])).stringof); // writes const(int)[] not int[]
Adding the following near line 1188 of traits.d solves this problem:
template Unqual(T : U[], U) { alias U[] Unqual; }
Comment #1 by dsimcha — 2009-12-02T12:39:37Z
This behavior is by design. Unqual is supposed to shallowly strip const, etc, not deeply strip it.
Comment #2 by lat7h — 2009-12-02T12:46:35Z
Then I propose this design decision ought to be made explicit in the documentation; "removes all qualifiers" seemed, to me, to imply removing *all* qualifiers, not just the top level.
Comment #3 by default_357-line — 2018-06-18T07:25:35Z
This bug needs a second look.
Consider this code:
struct S
{
int* ipointer;
}
pragma(msg, (Unqual!(const S)).stringof);
As can be seen, Unqual has just deeply stripped const, not shallowly.
Either Unqual must be made to error when passed a const struct with reference, or Unqual must leave const(int[]) as int[].
The current state is broken.
Comment #4 by schveiguy — 2018-06-18T14:37:57Z
This is likely going to be disruptive to fix, so many things use Unqual. But nonetheless, it's an important bug.
Comment #5 by timosesu — 2018-07-12T08:56:15Z
The fact the Unqual only "shallowly" unqualifies a type can be pretty annoying when dealing with templates and inout functions.
struct S
{
int[] vals;
}
template Temp(T)
{
class Temp
{
T t;
this(T t)
{ this.t = t; }
auto get() inout
{
static if (is(T == S))
{
import std.traits : Unqual;
alias tType = Unqual!(typeof(t.vals));
pragma(msg, tType); // inout(int)[]
return new inout Temp!tType(t.vals); // ERROR: Can't create class Temp!(inout(int)[])
}
}
}
}
unittest
{
auto t = Temp!S;
t.get();
}
Error: variable `onlineapp.Temp!(inout(int)[]).Temp.t` only parameters or stack based variables can be inout
Error: template instance `onlineapp.Temp!(inout(int)[])` error instantiating
In this case a complete stripping of qualifiers is required!
Related discussion: https://forum.dlang.org/post/[email protected]
Comment #6 by schveiguy — 2018-07-12T12:28:57Z
Note, the bug here in FeepingCreature's case is that it strips more than it should. It is supposed to be safe to use Unqual.
So the expectation that Unqual should remove all mutability modifiers is incorrect.
I'm changing the title accordingly. Perhaps we should actually close this bug and open another, as the whole issue has really been flipped around?
Comment #7 by timosesu — 2018-07-12T14:36:46Z
(In reply to Steven Schveighoffer from comment #6)
> I'm changing the title accordingly. Perhaps we should actually close this
> bug and open another, as the whole issue has really been flipped around?
Perhaps you're looking for this? https://issues.dlang.org/show_bug.cgi?id=8338
Comment #8 by timosesu — 2018-07-12T15:02:58Z
(In reply to Steven Schveighoffer from comment #6)
> Note, the bug here in FeepingCreature's case is that it strips more than it
> should. It is supposed to be safe to use Unqual.
>
> So the expectation that Unqual should remove all mutability modifiers is
> incorrect.
Tried to find examples where a complete stripping of qualifiers would break something. I guess here it is really required that it only strips the "head" qualifier:
https://github.com/dlang/phobos/blob/90a8fc387f25f9bdfc2c6ad4508da63c523be670/std/array.d#L1465
Though this is not the subject of this issue.. Should I perhaps create a new issue for https://issues.dlang.org/show_bug.cgi?id=3567#c5 ? Perhaps asking for a new trait?
Comment #9 by schveiguy — 2018-07-12T15:11:44Z
I think a trait "ForceUnqual" may be needed in some cases, but "Unqual" I have always expected to behave the way it does (except in the case of structs containing references, for which it should not strip anything).
Man, it would be nice to have a tail-modifier in D...
Comment #10 by bugzilla — 2019-12-12T11:45:34Z
*** Issue 8338 has been marked as a duplicate of this issue. ***
Comment #11 by robert.schadek — 2024-12-01T16:13:17Z