[cfe-dev] [RFC PATCH] C++0x trailing return type
Daniel Wallin
daniel at boostpro.com
Thu Sep 23 01:49:22 PDT 2010
Accidentally left out the list cc in my first response:
On Thu, Sep 23, 2010 at 1:07 AM, Daniel Wallin <daniel at boostpro.com> wrote:
> On Wed, Sep 22, 2010 at 8:49 PM, Sebastian Redl
> <sebastian.redl at getdesigned.at> wrote:
>>
>> On Sep 22, 2010, at 11:30 AM, Daniel Wallin wrote:
>>
>>> <trailing-return.patch>
>>
>> Very nice! One important thing, though, is that the trailing return type is really a property of the declaration, not of the type. In particular, you made type uniquing dependent on whether the return type is trailing, which is incorrect:
>> int f();
>> and
>> auto f() -> int;
>> declare the same function; the type is the same.
>
> Ah yes, good point. The only reason I had to attach the property at
> all was because I needed access to it when transforming the function
> type, so that this order:
>
> // We instantiate in source order, with the return type first followed by
> // the parameters, because users tend to expect this (even if they shouldn't
> // rely on it!).
>
> could be switched in TreeTransform.h. Any ideas on where the property
> could be stored? Keep in mind that for things like:
>
> X<auto(int) -> int>
>
> there is no Decl for the function type. I could hack this by moving
> the HasTrailing bool to FunctionLocInfo, but since I don't have a very
> good idea on what TypeLoc's are, I have no idea if that's a viable
> solution. ;)
I'm attaching a patch that does that.
--
Daniel Wallin
BoostPro Computing
http://www.boostpro.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trailing-return-2.patch
Type: application/octet-stream
Size: 15083 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20100923/634adb3f/attachment.obj>
More information about the cfe-dev
mailing list