Bug 7717 – Regression(2.059): typeof(this) incorrect in mixin template

template IsValid(T) { enum IsValid = is(typeof(T.init.x)); } mixin template T() { static assert(IsValid!(typeof(this))); } struct S { int x; mixin T; } The IsValid template is not necessary to reproduce the problem - it's for illustration. This also fails: static assert(is(typeof(typeof(this).init.x))); But not this: static assert(is(typeof(x)));

It's not clear that there's a bug here. typeof(this).init correctly shouldn't compile inside a mixin, because the mixin might add an extra field -- so then init would change. .init is defined only when all possible members of the aggregate have been declared. Can you come up with a valid example?

(In reply to comment #1) > It's not clear that there's a bug here. typeof(this).init correctly shouldn't > compile inside a mixin, because the mixin might add an extra field It does not add an extra field. > -- so then init would change. If I added some random character to a valid d program, then it would likely not be valid anymore. What does this prove? > > .init is defined only when all possible members of the aggregate have been > declared. This is the case in the example. What should be illegal is adding a field that changes .init based on a static condition that depends on .init. This would be part of a necessary general overhaul of symbol lookup works in DMD: Forward declarations and compile-time reflection make it possible to write contradictory or ambiguous D programs. The compiler should detect such setups in the least conservative way we can come up with.

If this behavior is invalid by design, then the error message should be improved (e.g. to ".init not known at this point" or "recursive semantic analysis attempt on S"). The workaround is to use std.traits.hasMember (which, underneath, uses __traits(allMembers, T)).

> then the error message should be improved Never mind, the check is inside an is() condition - so AFAIU any errors should be silenced.

(In reply to comment #2) > (In reply to comment #1) > > It's not clear that there's a bug here. typeof(this).init correctly shouldn't > > compile inside a mixin, because the mixin might add an extra field > > It does not add an extra field. > > > -- so then init would change. > > If I added some random character to a valid d program, then it would likely not > be valid anymore. What does this prove? The point is that accessing .init from inside a mixin is not valid in the general case. Although in this specific example, it could be made to work, that isn't true in general. Likewise, .sizeof is not defined until all declarations have been run. > > .init is defined only when all possible members of the aggregate have been > > declared. > > This is the case in the example. What should be illegal is adding a field that > changes .init based on a static condition that depends on .init. This would be > part of a necessary general overhaul of symbol lookup works in DMD: Forward > declarations and compile-time reflection make it possible to write > contradictory or ambiguous D programs. The compiler should detect such setups > in the least conservative way we can come up with. OK. That's clearly an enhancement request. Compiler is working as designed. This only seemed to compile before, because of a compiler bug.

The change in behaviour is probaby related to the fixes for bug 3509 and bug 3510.

Status in 2.061: The OP sample works, however: > This also fails: > static assert(is(typeof(typeof(this).init.x))); > But not this: > static assert(is(typeof(x))); Both of these fail now.

(In reply to comment #7) > Both of these fail now. Those assert lines should be placed instead of the assert line in the example code. All of the cases presented seem to work in DMD 2.061.