digitalmars.D.bugs - [Issue 7717] New: Regression(2.059): typeof(this) incorrect in mixin template
- d-bugmail puremagic.com (36/36) Mar 15 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (15/15) Mar 16 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (19/25) Mar 16 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (10/10) Mar 16 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (7/8) Mar 16 2012 Never mind, the check is inside an is() condition - so AFAIU any errors ...
- d-bugmail puremagic.com (12/31) Mar 16 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (7/7) Apr 02 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (9/9) Apr 05 2012 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (12/16) Jan 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7717
- d-bugmail puremagic.com (14/15) Jan 12 2013 http://d.puremagic.com/issues/show_bug.cgi?id=7717
http://d.puremagic.com/issues/show_bug.cgi?id=7717 Summary: Regression(2.059): typeof(this) incorrect in mixin template Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: thecybershadow gmail.com 17:05:19 PDT --- 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))); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 15 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au 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? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717 timon.gehr gmx.ch changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |timon.gehr gmx.chIt'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 fieldIt 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717 08:44:28 PDT --- 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)). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717 09:03:39 PDT ---then the error message should be improvedNever mind, the check is inside an is() condition - so AFAIU any errors should be silenced. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Mar 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717The 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.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 fieldIt 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?OK. That's clearly an enhancement request. Compiler is working as designed. This only seemed to compile before, because of a compiler bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------.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.
Mar 16 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717 The change in behaviour is probaby related to the fixes for bug 3509 and bug 3510. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 02 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717 Walter Bright <bugzilla digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla digitalmars.com Severity|regression |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Apr 05 2012
http://d.puremagic.com/issues/show_bug.cgi?id=7717 Andrej Mitrovic <andrej.mitrovich gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |andrej.mitrovich gmail.com 20:22:27 PST --- 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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 12 2013
http://d.puremagic.com/issues/show_bug.cgi?id=7717 Vladimir Panteleev <thecybershadow gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME 06:37:26 EET ---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. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 12 2013