<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Dec 5, 2008, at 8:25 PM, Sebastian Redl wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Douglas Gregor wrote:<br><blockquote type="cite">On Dec 5, 2008, at 8:01 PM, Sebastian Redl wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Looks pretty good. I'm a bit worried that this approach means that pretty much every bit of Sema code that does some kind of type or capability checking has to be aware of template types and defer their checking. Is this correct? If so, is there any way we can avoid it? I'm envisioning bugs en masse that only appear in template code.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This is absolutely correct. Before checking whether a particular expression or declaration is valid, we will need to check whether its parts are dependent (dependent types, type-dependent expressions, value-dependent expressions, etc.).<br></blockquote>OK, at the very least, we need a simple way to do this (Expr::isDependent()). But undoubtedly you're planning that already.</div></blockquote><div><br></div><div>Yeah, we'll have</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Type::isDependentType()<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Expr::isValueDependent()<br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Expr::isTypeDependent()</div><div><br></div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite">Frankly, I don't think there's any way around it.<br></blockquote>I was afraid of that. And I'm also afraid that we'll have yet another case when we get concepts, because I don't think that constrained type parameters are quite the same as concrete types. Or are they?</div></blockquote><div><br></div><div>They're similar. When type-checking in the presence of concepts, we treat types that would be dependent via nearly-concrete types called "archetypes". I believe that archetypes will fit beautifully into our canonical type system :)</div><br><blockquote type="cite"><div><br><blockquote type="cite">Getting some level of template support into the compiler early perhaps means that we can be conscientious about adding template support for something as soon as we add the non-template support for it. We should try to enforce this through the type system.<br></blockquote>Hmm ...<br><br>Anyway, it'll also need restructuring so that all the checkers can be called from the template instantiator. We definitely have a lot of work ahead.</div></blockquote><div><br></div><div>Yeah, and SFINAE makes this doubly interesting, because we have to be able to say: oops, we hit a problem during instantiation, back out and be quiet about it.</div><div><br></div><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">The dependent-types computation will be coming later today.<br></blockquote>3 and a half hours left of today where I am, but I'm looking forward to it. ;-)</div></blockquote><div><br></div>I'm typing as fast as I can :)</div><div><br></div><div><blockquote type="cite"><div>By the way, how does GCC do this stuff?<br></div></blockquote></div><div><br></div><div>GCC's approach is pretty similar to what I'm planning for Clang because, well, GCC does it the right way. This approach gives us the best ASTs and the most type-checking at template definition time, which will put us in the right place for eventually implementing concepts where *everything* is type-checked at template definition time.</div><br><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>