It seems to me that the distinction between QualType and Type is an implementation detail that we shouldn't bother users with. If we make everything a QualType, the users will have the same functionality in a more easily readable format. I don't really see any disadvantages to this approach. You mentioned that this would "kill the type safety for the matchers"--what did you mean exactly?<div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Aug 22, 2012 at 10:16 AM, Manuel Klimek <span dir="ltr"><<a href="mailto:klimek@google.com" target="_blank">klimek@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
+mdiamond, who is interested in contributing here<br>
<br>
On Wed, Aug 1, 2012 at 12:21 PM, Richard Smith <<a href="mailto:richard@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:<br>
> On Wed, Aug 1, 2012 at 7:01 AM, Manuel Klimek <<a href="mailto:klimek@google.com">klimek@google.com</a>> wrote:<br>
>><br>
>> Given Sam's open review, I've been pondering how to implement a type<br>
>> matcher (so far we've punted on that).<br>
>> The obvious idea would be to have a type() function that returns a<br>
>> Matcher<QualType>. Apart from some technical hoops to jump through I<br>
>> have a patch ready for that.<br>
>><br>
>> This leads to a different design decision, though. We'll want type()<br>
>> to return a BindableMatcher, and for that we need to implement type<br>
>> binding. This is not quite straight forward, as types are split into<br>
>> QualType and Type nodes in the AST, and only the Type nodes model the<br>
>> inheritance hierarchy. My understanding is that this is for<br>
>> performance reasons, so that every Type* exists only once, and<br>
>> equality on types can be implemented by a pointer comparison.<br>
>><br>
>> The question is: how much of that do we want to express in the matcher<br>
>> language.<br>
>> I see two main options:<br>
>> 1. Fully model that relationship. When somebody writes matchers for<br>
>> types, they will look like this:<br>
>> qualType(arrayType(hasElementType(qualType(asString("int"))))<br>
>><br>
>> 2. Model QualTypes in the matchers, and allow going "through" to the<br>
>> underlying type; this will kill the type safety for the matchers, but<br>
>> will make the matcher expressions more concise:<br>
>> arrayType(hasElementType(asString("int")))<br>
><br>
><br>
> Is there a fundamental reason why we can't have the best of both? That is, a<br>
> matcher which matches Type *or* QualType, and constrains its inner matchers<br>
> to match ArrayType.<br>
</blockquote></div><br></div>