[cfe-dev] blocks and lambdas

[David Chisnall]

On 9 Feb 2011, at 07:57, James Gregurich wrote:

> I'm not interested in stepping on anyone's favorite technology. If you love Blocks and gnustep that is wonderful!
> 
> lambdas are part of the C++0x standard. Therefore, it is a mechanism all C++ compiler vendors will eventually support. My company does commercial desktop development and the "cross-platform" that matters to us is Macintosh gcc/clang and Visual-C++. It is highly unlikely that Microsoft will ever support Blocks (they don't even support C99)...particularly given they have already implemented lambda support in VC++. Therefore, it is in my interest to make sure Apple's tools offer first-class support for as many standard C++ technologies as possible so that my development burden is eased. I envision that lambdas will be a big part of my future and I wanted find out what direction clang is taking on lambda support.


Lambdas and blocks are orthogonal technologies.  Blocks are a C extension designed to interoperate nicely with Objective-C and to work with C++.  Lambdas are a (very different) C++ technology.  Saying that you want a C library (libdispatch) to support a C++ technology (lambdas) doesn't make much sense.  

Given the different semantics between blocks and lambdas, implementing one in terms of the other does not really make sense.  However, it would be fairly simple at the library level to implement a wrapper for one in terms of the other, so this isn't a compiler issue, it's an issue for your code.  

Having blocks and labmdas share an implementation in clang would be problematic for a variety of reasons.  For one thing, blocks already have a well-defined ABI, and lambdas will have a per-platform ABI.  Unless you could persuade the C++ committee to break with tradition and specify an ABI, and specify that ABI to be compatible with the existing, deployed, blocks ABI, then this is not feasible.  

David

-- Send from my Jacquard Loom