[cfe-commits] [PATCH] Suggested rewording for lamba return values

[Richard Smith]

The patch itself LGTM.

Doug: Are you OK with this? I don't recall if you wanted to wait until
3.1 shipped or until Portland :)

On Fri, Jun 1, 2012 at 5:36 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
> Ping?
>
> On Mon, May 28, 2012 at 6:33 PM, Aaron Ballman <aaron at aaronballman.com> wrote:
>> On Thu, May 24, 2012 at 10:36 AM, Aaron Ballman <aaron at aaronballman.com> wrote:
>>> On Thu, May 24, 2012 at 12:50 AM, Richard Smith <richard at metafoo.co.uk> wrote:
>>>> On Tue, May 22, 2012 at 6:54 PM, Aaron Ballman <aaron at aaronballman.com>
>>>> wrote:
>>>>>
>>>>> When a lambda expression omits the return type information, the
>>>>> standard requires the lambda statement body to be a single return
>>>>> statement.  However, as a language extension, we (and several other
>>>>> compilers) support determining the return type if all of the
>>>>> function's return types agree.
>>>>>
>>>>> The problem is, the wording for the warning we emit is a bit difficult
>>>>> to parse.  It's a semantically correct statement, but it's not
>>>>> immediately obvious what the problem is or how to rectify it.
>>>>> Consider:
>>>>>
>>>>> auto i = []() { static const int foo = 12; return &foo; }();
>>>>>
>>>>> This will emit a diagnostic that says "C++11 requires lambda with
>>>>> omitted result type to consist of a single return statement" --
>>>>> however, a likely initial response to this is "but I do only have a
>>>>> single return statement!"
>>>>>
>>>>> This patch rewords the diagnostic to be a bit more clear (hopefully):
>>>>> "C++11 requires a lambda expression with omitted result type to
>>>>> consist solely of a return statement"
>>>>>
>>>>> Thoughts?
>>>>
>>>>
>>>> I would be in favor of removing the warning entirely, now that Clang 3.1 has
>>>> shipped. The C++ core working group has already agreed that this should be
>>>> allowed. It's currently under consideration by the evolution working group,
>>>> whom I think are unlikely to say no -- and if they do, we will have time to
>>>> react before 3.2 is released.
>>>
>>> That would certainly work as well -- is there a general preference one
>>> way or the other?
>>>
>>> ~Aaron
>>
>> Here is a patch that removes the warning entirely as per Richard's
>> suggestion -- any objections?
>>
>> ~Aaron