Bug 10722 – Regression (2.064 git-head): Cannot interpret struct at compile-time

----- struct Struct { int x; } template GetSomething(S...) { alias GetSomething = int; } void main() { alias X = GetSomething!(Struct.tupleof[0]); } ----- > Error: Cannot interpret Struct at compile time

Introduced by e1ce57e - Merge pull request #2136 from donc/future_of_ctfe https://github.com/D-Programming-Language/dmd/pull/2136

Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a8d1df98864cd27d14da2ac7477ed53a9ec223f5 fix Issue 10722 - Regression (2.064 git-head): Cannot interpret struct at compile-time https://github.com/D-Programming-Language/dmd/commit/aa8b1b8797f0faa26637bddd4cf30940ec43b471 Merge pull request #2477 from 9rnsr/fix10722 [REG2.064a] Issue 10722 - Cannot interpret struct at compile-time

(In reply to comment #3) > Commits pushed to master at https://github.com/D-Programming-Language/dmd > > https://github.com/D-Programming-Language/dmd/commit/a8d1df98864cd27d14da2ac7477ed53a9ec223f5 > fix Issue 10722 - Regression (2.064 git-head): Cannot interpret struct at > compile-time > > https://github.com/D-Programming-Language/dmd/commit/aa8b1b8797f0faa26637bddd4cf30940ec43b471 > Merge pull request #2477 from 9rnsr/fix10722 > > [REG2.064a] Issue 10722 - Cannot interpret struct at compile-time This fix has changed the behavior of .stringof. Before the fix: struct Foo { int a; } static assert(Foo.tupleof[0].stringof == "(Foo).a"); After the fix: static assert(Foo.tupleof[0].stringof == "a"); This has broken my library Orange, which is being integrated as std.serialization.

(In reply to comment #4) > This has broken my library Orange, which is being integrated as > std.serialization. Using .stringof is very unreliable (precisely because of these sort of changes, and since .stringof isn't really properly defined). I suggest using __traits(identifier, Foo.tupleof[0]) instead.

(In reply to comment #5) > (In reply to comment #4) > > This has broken my library Orange, which is being integrated as > > std.serialization. > > Using .stringof is very unreliable (precisely because of these sort of changes, > and since .stringof isn't really properly defined). > > I suggest using __traits(identifier, Foo.tupleof[0]) instead. Today stringof property merely prints the internal AST which its semantic analysis has been done. And of course internal AST format does not have any backward compatibility beyond compiler releases. (Note that compiler cannot determine the stringof property result before semantic analysis, because the property could be overridden by user-defined field.) So the result format is not defined at all.

(In reply to comment #5) > Using .stringof is very unreliable (precisely because of these sort of changes, > and since .stringof isn't really properly defined). > > I suggest using __traits(identifier, Foo.tupleof[0]) instead. I suspected that, that was why I didn't create a new bug report.

(In reply to comment #6) > Today stringof property merely prints the internal AST which its semantic > analysis has been done. > And of course internal AST format does not have any backward compatibility > beyond compiler releases. > > (Note that compiler cannot determine the stringof property result before > semantic analysis, because the property could be overridden by user-defined > field.) > > So the result format is not defined at all. I understand that, but it has stayed the same of the last 6-7 years. This should be clearly stated in the documentation. Or it should be defined.

.stringof representation has changed in many parts of the compiler, I guess this current usage of it had the biggest effect yet. I suggest we add a note in the documentation to avoid using .stringof for code-generation, and prefer things like __traits(identifier), or one of the Phobos helper functions such as "fullyQualifiedName".