www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3416] New: Non-compilable template instantiation in is(typeof()) fails compilation

reply d-bugmail puremagic.com writes:
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
next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3416





 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.
 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
prev sibling next sibling parent d-bugmail puremagic.com writes:
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.
I think you're overstating the problem. Certainly it's an annoyance. But in my experience it is quite easy to work around it.
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.
 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.
Should I post another report? And what about D1 that does not have __traits?
 
 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.
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: -------
Oct 21 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
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
prev sibling parent d-bugmail puremagic.com writes:
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