On Jun 4, 2012, at 11:36 AM, Richard Smith <[email protected]> wrote:
> 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 :)
Yep, this is fine.
- Doug
> On Fri, Jun 1, 2012 at 5:36 PM, Aaron Ballman <[email protected]> wrote:
>> Ping?
>>
>> On Mon, May 28, 2012 at 6:33 PM, Aaron Ballman <[email protected]>
>> wrote:
>>> On Thu, May 24, 2012 at 10:36 AM, Aaron Ballman <[email protected]>
>>> wrote:
>>>> On Thu, May 24, 2012 at 12:50 AM, Richard Smith <[email protected]>
>>>> wrote:
>>>>> On Tue, May 22, 2012 at 6:54 PM, Aaron Ballman <[email protected]>
>>>>> 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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
