digitalmars.D.bugs - [Issue 3416] New: Non-compilable template instantiation in is(typeof()) fails compilation
- d-bugmail puremagic.com (32/32) Oct 18 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (10/10) Oct 18 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (13/13) Oct 18 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (27/27) Oct 19 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (21/21) Oct 19 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (16/16) Oct 19 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (15/15) Oct 19 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (13/22) Oct 19 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (32/55) Oct 21 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (7/7) Oct 28 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
- d-bugmail puremagic.com (15/15) Oct 28 2009 http://d.puremagic.com/issues/show_bug.cgi?id=3416
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Summary: Non-compilable template instantiation in is(typeof()) fails compilation Product: D Version: 2.035 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nobody puremagic.com ReportedBy: samukha voliacable.com PDT --- template bar() { void bar() { a b; // invalid code } } template foo() { enum foo = is(typeof(bar!())); } enum c = foo!(); test.d(19): Error: identifier 'a' is not defined test.d(19): Error: a is used as a type test.d(19): Error: variable Test.bar!().bar.b voids have no value -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 18 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Max Samukha <samukha voliacable.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker PDT --- Looks like a blocker for QtD -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 18 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Brad Roberts <braddr puremagic.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |braddr puremagic.com --- How can invalid code be considered a blocker for anything? Blockers are for problems that have no work around. The work around for invalid code is obvious. Am I missing something? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 18 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 PDT --- That is just a minimal test case. We should be able to check if a template can be instantiated with given template arguments. Here is a better test case: template bar(T) { void baz() { T a; a = null; // this may or may not be valid code, depending on T } } enum foo = is(typeof(bar!int)); // this should evaluate to false ---- test.d(22): Error: cannot implicitly convert expression (null) of type void* to int May be a regression. Note that the following compiles as expected: template bar(T) { T a = null; // this may or may not be valid code, depending on T } static assert(!is(typeof(bar!int))); static assert(is(typeof(bar!(void*)))); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 19 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 PDT --- Interestingly, if 'foo' is instantiated in 'static assert', is incorrectly evaluated to true. template bar(T) { private void baz() { T a = null; } } template foo(T) { enum foo = is(typeof(bar!T)); } static assert(!foo!int); ---- Error: static assert (!true) is false -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 19 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Don <clugdbug yahoo.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clugdbug yahoo.com.au I don't think this is a bug. You're assuming that is(typeof(X)) is a test for whether X compiles. But it isn't. is(typeof(X)) only checks if the X has a semantically valid type. And in this case it does, because it's declared as void. There's a larger issue, in that is(typeof(X)) is ugly, and it's very common to want to see if something compiles. In fact it's arguably the ugliest thing in the language right now. But it's not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 19 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 PDT --- Ok, but there is no other way to determine if some syntactically correct code is also correct semantically. And without that, D's metaprogramming system is of little use. Anyway, I'm not sure whether semantically incorrect code should produce a valid type, which void is. Should it? And the current compiler seems to treat __traits(compiles, X) and is(typeof(X)) identically... I think this bug should remain open until is(typeof(X)) is fixed or a different/better mechanism is introduced. And it is definitely a blocker. Thanks -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 19 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416Ok, but there is no other way to determine if some syntactically correct code is also correct semantically. And without that, D's metaprogramming system is of little use.I think you're overstating the problem. Certainly it's an annoyance. But in my experience it is quite easy to work around it.Anyway, I'm not sure whether semantically incorrect code should produce a valid type, which void is. Should it?Dunno. To avoid that, it would have to instantiate the body of every template, recursively.And the current compiler seems to treat __traits(compiles, X) and is(typeof(X)) identically...THAT is definitely a bug.I think this bug should remain open until is(typeof(X)) is fixed or a different/better mechanism is introduced. And it is definitely a blocker.A comment: 30% of the blockers in Bugzilla are from you. None of them have any votes, not even from you. You might want to change that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 19 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 PDT ---I don't think so. I intend to base a design on a feature that seems to work: template bar(T) { T a = null; } template foo(T) { enum foo = is(typeof(bar!(T))); } static assert(!foo!(int)); static assert(foo!(void*)); The above looks logical, regardless of the syntax. By extension, I conclude that it will work in more complex cases. I squeal with delight. Then it appears that the feature doesn't work and is not supposed to work at all. Now I have to introduce hacks (if we stop calling them workarounds, the world may change for the better) or rethink the design. It is not just an annoyance but another massive WTF. I wouldn't be whining here if those annoyances weren't so frequent.Ok, but there is no other way to determine if some syntactically correct code is also correct semantically. And without that, D's metaprogramming system is of little use.I think you're overstating the problem. Certainly it's an annoyance. But in my experience it is quite easy to work around it.Should I post another report? And what about D1 that does not have __traits?Anyway, I'm not sure whether semantically incorrect code should produce a valid type, which void is. Should it?Dunno. To avoid that, it would have to instantiate the body of every template, recursively.And the current compiler seems to treat __traits(compiles, X) and is(typeof(X)) identically...THAT is definitely a bug.clear specification even in those dark times. I was green and it took me a while to get used to the D way (more powerful language at a price of buggy toolchain and incomplete specification). Anyway, only 3 of the blockers has remained open. One was a blocker for a design I eventually gave up on because of it and other bugs. Another I've changed to normal. The third is this one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------I think this bug should remain open until is(typeof(X)) is fixed or a different/better mechanism is introduced. And it is definitely a blocker.A comment: 30% of the blockers in Bugzilla are from you. None of them have any votes, not even from you. You might want to change that.
Oct 21 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 This seems to be a duplicate of bug 965. My comments were based on Walter's comment in that bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 28 2009
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Max Samukha <samukha voliacable.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |DUPLICATE Severity|blocker |normal PDT --- I think, you are right. No point in further analysis if the type can be determined without it. Sorry for the rant. I'll post a bug concerning __traits(compiles), then. *** This issue has been marked as a duplicate of issue 965 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Oct 28 2009