--- Comment #8 from Max Samukha <> 2009-10-21 07:52:43 
PDT ---
(In reply to comment #7)
> (In reply to comment #6)
> > 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

> > 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.

Thanks for the comment. I came from C# that had a very stable toolchain and
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:
------- You are receiving this mail because: -------

Reply via email to