[cfe-dev] blocks and lambdas

[James Gregurich]

point taken. However, I'm sure this list is loaded with apple compiler engineers and I'm here to voice my needs to you guys on the inside in person and early enough in the process to matter. I can indeed file a feature request with Apple. Based on what I am hearing here, I'm confident you guys are on a path that I will be happy with.

-James

Sent from my iPad

On Feb 8, 2011, at 4:28 PM, Chris Lattner <clattner at apple.com> wrote:

> James, clang doesn't even support lambdas at all yet... I think you are putting the cart before the horse.
> 
> Also, clang is not in charge of defining Mac Apis.  If you want some API to work with lambdas, you should file a bug report at apple's bugtracker.
> 
> -Chris
> 
> On Feb 8, 2011, at 3:39 PM, James Gregurich <bayoubengal at mac.com> wrote:
> 
>> 
>> given the lambda is the cross-platform standard, I think being able to pass the lambda to the Cocoa callback-using APIs and to libdispatch is the useful situation....ie...lambda being able to masquerade as a block and interoperate cleanly with Apple's home-grown infrastructure.  If I can write my code entirely in terms of lambda's and that code works with Apple's native stuff, I can't image why I would want to use a block with standard code. If did want to put a block into a STL container or some such thing, I could certainly create a wrapper template that performed the Block_copy.
>> 
>> If you can make that functionality happen, then I suppose that it will meet my needs and I'll be happy.
>> 
>> -James
>> 
>> On Feb 8, 2011, at 11:03 AM, John McCall wrote:
>> 
>>> On Feb 8, 2011, at 10:44 AM, James Gregurich wrote:
>>>> On Feb 7, 2011, at 8:00 PM, John McCall wrote:
>>>>> On Feb 7, 2011, at 6:33 PM, James Gregurich wrote:
>>>>>> What if you build your lambda structure around the existing block structure such that the lambda type would have a copy constructor that calls Block_copy? If the lambda has a type, it stands to reason that it could have a copy constructor.
>>>>> 
>>>>> You seem to be describing a transformation which would occur when a block pointer is treated like a lambda.
>>>> 
>>>> no. not really a "transformation"...more of a syntactic wrapper.  you control your compiler and runtime. When clang hits a lambda in C++ code, I assume the backend could generate a block structure to implement the lambda. Also, if the lambda has a c++ type, then it could also have a copy constructor to invoke Block_copy so that the mechanism works normally with stl. Is such an assumption off-base?
>>> 
>>> Okay, this is the opposite direction of interoperability from what I thought you were talking about;  this is using a lambda expression as if it were a block.  I certainly would like this to work;  this is what I was getting at by saying "an implicit conversion to the appropriate block pointer type".  We probably won't use the standard block layout, though, because it's a pretty substantial size overhead (4-5 pointers) that most C++ clients won't want.  Obviously, when a lambda expression is immediately converted to a block pointer, we'll want to just build it as a block in the first place.
>>> 
>>>>> That's not actually a knowable point in a program.
>>>> 
>>>> I don't understand what you mean by this statement.
>>> 
>>> I was talking about the opposite direction of interoperability, i.e. using a block expression or block pointer as if it were a lambda.  This is what's unsafe because of the dangling-pointer issue and that we can't really make safe because of how lambdas work.
>>> 
>>> John.
>> 
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev