Bug 8338 – Unqual's documentation doesn't reflect its behavior on types with indirections
Status
RESOLVED
Resolution
DUPLICATE
Severity
normal
Priority
P2
Component
phobos
Product
D
Version
D2
Platform
All
OS
All
Creation time
2012-07-02T19:12:33Z
Last change time
2019-12-12T11:45:34Z
Assigned to
No Owner
Creator
Jonathan M Davis
Comments
Comment #0 by issues.dlang — 2012-07-02T19:12:33Z
Take this bit of code
import std.stdio;
import std.traits;
void main()
{
writeln(Unqual!(char[]).stringof);
writeln(Unqual!(wchar[]).stringof);
writeln(Unqual!(dchar[]).stringof);
writeln(Unqual!(const char[]).stringof);
writeln(Unqual!(const wchar[]).stringof);
writeln(Unqual!(const dchar[]).stringof);
writeln(Unqual!string.stringof);
writeln(Unqual!wstring.stringof);
writeln(Unqual!dstring.stringof);
writeln();
writeln(Unqual!(ubyte[]).stringof);
writeln(Unqual!(short[]).stringof);
writeln(Unqual!(uint[]).stringof);
writeln(Unqual!(const ubyte[]).stringof);
writeln(Unqual!(const short[]).stringof);
writeln(Unqual!(const uint[]).stringof);
writeln(Unqual!(immutable ubyte[]).stringof);
writeln(Unqual!(immutable short[]).stringof);
writeln(Unqual!(immutable uint[]).stringof);
}
It prints out
char[]
wchar[]
dchar[]
const(char)[]
const(wchar)[]
const(dchar)[]
string
immutable(wchar)[]
immutable(dchar)[]
ubyte[]
short[]
uint[]
const(ubyte)[]
const(short)[]
const(uint)[]
immutable(ubyte)[]
immutable(short)[]
immutable(uint)[]
None of those const or immutables should be there. The only changes between this and not using Unqual at all is the const T[] are now const(T)[] and the immutable T[] are now immutable(T)[]. And the immutable(T)[], are still immutable(T)[]. The immutable on their elements aren't stripped.
Unqual specifically states that it removes _all_ qualifiers. It's clearly only removing them from the array itself and not the elements, so it's not removing all of the qualifiers.
Comment #1 by k.hara.pg — 2012-07-02T19:40:39Z
(In reply to comment #0)
> Take this bit of code
>
[snip]
>
> None of those const or immutables should be there. The only changes between
> this and not using Unqual at all is the const T[] are now const(T)[] and the
> immutable T[] are now immutable(T)[]. And the immutable(T)[], are still
> immutable(T)[]. The immutable on their elements aren't stripped.
>
> Unqual specifically states that it removes _all_ qualifiers. It's clearly only
> removing them from the array itself and not the elements, so it's not removing
> all of the qualifiers.
Yes. std.traits.Unqual removes the top qualifier of given type, not all ones.
But, changing its implementation would break *maby* existing codes, so, instead, we should fix its documentation.
Comment #2 by k.hara.pg — 2012-07-02T19:41:54Z
> But, changing its implementation would break *maby* existing codes, so,
s/maby/many/
Comment #3 by issues.dlang — 2012-07-02T20:03:22Z
Maybe. But I'm not completely convinced that it would break all that much code - particularly since I would have expected any code using Unqual to be written with the intention of stripping _all_ of the qualifiers (as the documentation says). If we don't make the change though, we need a new template similar to Unqual (FullUnqual? RecUnqual?) which really _does_ strip all of the qualifiers.
Comment #4 by k.hara.pg — 2012-07-02T21:01:13Z
(In reply to comment #3)
> Maybe. But I'm not completely convinced that it would break all that much code
> - particularly since I would have expected any code using Unqual to be written
> with the intention of stripping _all_ of the qualifiers (as the documentation
> says).
But, getting type stripped full qualifiers is much unsafe than just top.
const string s = "Hello"; // const(immutable(char)[])
auto mutable_s = cast(Unqual!(typeof(s)))s; // ???
In many cases, current Unqual is used with unsafe casting, even if it is bad idiom. Changing the implementation of Unqual will become such codes *more* unsafe silently.
(As far as I know, Phobos doesn't have such bad using. I'm talking about the user codes written by programmers don't know well about const/immutable type system.)
And in (sadly) few cases that uses Unqual correct way, it will change codes from safe to unsafe.
Stripping top qualifier of array/string types:
https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1634https://github.com/D-Programming-Language/phobos/blob/master/std/format.d#L1705
> If we don't make the change though, we need a new template similar to
> Unqual (FullUnqual? RecUnqual?) which really _does_ strip all of the
> qualifiers.
Noqual?
Or, add new two templates, one removes just top qualifier, another does all qualifiers. I think this is the best way, but have no idea about their names...
Comment #5 by peter.alexander.au — 2014-02-08T11:08:38Z
Are there actually any use cases for stripping all qualifiers? If there are no use cases then there is no point adding it. I can't think of any.
Comment #6 by simen.kjaras — 2018-01-26T13:57:33Z
This is a duplicate of bug 3567. As has been mentioned, changing what Unqual does is probably a bad idea, but the documentation does not in any way indicate that Unqual only strips the first layer of qualifier. The text should be updated to reflect this, and the examples should include const(int[]) and immutable(float*) or some otherwise fitting types.
Factored out Noqual as a separate proposal in bug 18302, leaving this one for the documentation for Unqual.
Comment #7 by timosesu — 2018-07-12T09:13:32Z
(In reply to Peter Alexander from comment #5)
> Are there actually any use cases for stripping all qualifiers? If there are
> no use cases then there is no point adding it. I can't think of any.
Please see in issue 3567 for an example use case where a full Unqual is required:
https://issues.dlang.org/show_bug.cgi?id=3567#c5
Comment #8 by bugzilla — 2019-12-12T11:45:34Z
*** This issue has been marked as a duplicate of issue 3567 ***