<div dir="ltr">On Tue, Jun 11, 2013 at 6:24 PM, Eli Friedman <span dir="ltr"><<a href="mailto:eli.friedman@gmail.com" target="_blank">eli.friedman@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Tue, Jun 11, 2013 at 3:09 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">For a Type held by an AST node, I completely agree, and I'll try to address that.  For a type held by a TypeSourceInfo, I disagree, the FunctionProtoType should really hold the undecayed parameter types.</div>

<div><div><div class="gmail_extra"></div></div></div></blockquote></div><br></div></div><div class="gmail_extra">Hmm... I was thinking more along the lines of keeping around the un-decayed type, but automatically decaying it for the user of the API unless they explicitly request the un-decayed version.  I'm not sure I like keeping different versions of the type in the AST nodes vs. TypeSourceInfo.</div>
</div></blockquote><div><br></div><div style>Maybe, but it seems pretty heavyweight to add a custom iterator to do the decay.  Right now the iterator is just an ArrayRef.  Every dynamic decay will trigger a uniquing in the ASTContext, unless we put some kind of cache into ArrayType or FunctionType similar to how CanonicalType works.</div>
</div></div></div>