On Thu, Jun 13, 2013 at 2:10 PM, Richard Smith <[email protected]>wrote:
> On Tue, Jun 11, 2013 at 3:24 PM, Eli Friedman <[email protected]> > wrote: > > On Tue, Jun 11, 2013 at 3:09 PM, Reid Kleckner <[email protected]> wrote: > >> > >> 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. > > > > > > 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. > > I have an alternative suggestion: introduce a DecayedType sugar node, > which is canonically the decayed pointer type, but also provides > access to the undecayed (array or function) type. 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
