<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 13, 2013 at 2:10 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank" class="cremed">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, Jun 11, 2013 at 3:24 PM, Eli Friedman <<a href="mailto:eli.friedman@gmail.com" class="cremed">eli.friedman@gmail.com</a>> wrote:<br>

</div><div><div class="h5">> On Tue, Jun 11, 2013 at 3:09 PM, Reid Kleckner <<a href="mailto:rnk@google.com" class="cremed">rnk@google.com</a>> wrote:<br>
>><br>
>> For a Type held by an AST node, I completely agree, and I'll try to<br>
>> address that.  For a type held by a TypeSourceInfo, I disagree, the<br>
>> FunctionProtoType should really hold the undecayed parameter types.<br>
><br>
><br>
> Hmm... I was thinking more along the lines of keeping around the un-decayed<br>
> type, but automatically decaying it for the user of the API unless they<br>
> explicitly request the un-decayed version.  I'm not sure I like keeping<br>
> different versions of the type in the AST nodes vs. TypeSourceInfo.<br>
<br>
</div></div>I have an alternative suggestion: introduce a DecayedType sugar node,<br>
which is canonically the decayed pointer type, but also provides<br>
access to the undecayed (array or function) type.</blockquote></div><br>I really like this strategy. It matches the architecture in lots of other places as well where we use sugar to denote the type as-written when distinct from the type as-canonically-used.</div>
</div>