alias T = int;
writeln(T.stringof);
Print int. This do not look like a big issue, but it makes most mixin fails, including phobos's ones, when used in templates. Things like this are going to fail hard with a very obscure error :
module a;
template Foo(T) { mixin(someting that use T.stringof); }
module b;
class C {}
import a;
Foo!C;
stringof will resolve as C, which do not exist in the template Foo, and all come to an halt.
This is causing a lot of trouble in SDC right now to pack thing in bitfield. Packing data is crucial for performance and memory consumption.
Comment #1 by bugzilla — 2015-01-17T21:14:51Z
Please have a compilable example.
Comment #2 by deadalnix — 2015-01-17T22:19:02Z
(In reply to Walter Bright from comment #1)
> Please have a compilable example.
alias T = int;
void main() {
writeln(T.stringof);
}
Here you go. This should print T, not int.
Comment #3 by deadalnix — 2015-01-17T22:29:02Z
Alternatively :
enum StringOf(T) = T.stringof;
void main() {
writeln(StringOf!uint);
}
This should also print T.
Comment #4 by issues.dlang — 2015-01-18T06:57:21Z
While I can certainly see why you'd want this (and it may very well be that we should make the change), I would point out that aliases _always_ disappear when they're used. I'm not aware of anywhere that the compiler treats the alias as anything other than the original to the point that it just about might as well be searching and replacing the alias with the original symbol in the text of the program. The alias never shows up in any error messages. So, having it show up with stringof would be a pretty major change with regards to how aliases are treated (be that for better or for worse).
As for this specific problem, I would point out that your initial example doesn't use aliases at all, so it doesn't show how the current behavior of stringof on an alias would actually cause compilation problems, and your follow up examples just show how stringof on an alias prints the original symbol rather than the alias name. They don't show how that actually causes problems.
So, as a follow up to what Walter requested, I'd ask that you provide an example that would compile if stringof on an alias gave the alias name rather than the original symbol name and which does not compile with the current behavior. So, it shows what you're actually trying to do but isn't working right now. As it stands, I don't understand what you're trying to do well enough to unnderstand why the current behavior is causing a problem, and I suspect that Walter is in the same boat.
Comment #5 by deadalnix — 2015-01-18T07:22:01Z
Johnatan, I made the sample code short so the problematic behavior can be demonstrated. I tried to explain where it causes problem, but apparently, I haven't been clear enough, so let me expand myself on the subject.
Consider the sample code :
module a;
struct S(E) {
import std.bitmanip;
mixin(bitfield!(
E, "e", 10,
uint, "", 6,
));
}
module b;
enum A { A, B }
import a;
S!A s;
There is absolutely no way to make that work (even when modifying bitfield) given the current behavior of stringof.
Chaging this will break huge amount of template code. I have personally written many snipppets that rely on the fact that template arguments resolve to underlying symbols. Actually, if this stops working, it will be rather hard to implement thing like `stringify!int == "int"` because __traits(identifier) works only on symbols.
Comment #8 by robert.schadek — 2024-12-13T18:38:52Z