You can keep a C++11 lambda alive after the stack frame disappears using copy semantics (the = modifier), which is what blocks are doing anyway; C++11, however, gives you more control, as whether a copy or a reference is taken is a property of the lambda, not the variable (as it is when using the __block modifiers). Also, not having a nameable type is a non-issue, due to templates, auto, and std::function (which is, in a way, the standard type you would actually use to deal with a lambda). If anything, lambdas have more type, as the type of a Block argument is erased in the type signature, even though it is required for the calling convention.

> You can keep a C++11 lambda alive after the stack frame disappears using copy semantics (the = modifier), which is what blocks are doing anyway

Ah, yes. Blocks allow you to keep mutable data alive without specifically moving them to the heap; in any case, simply having them is more important than those differences. I am not sure what you mean about types being erased.

C++11 supports mutable lambdas. The only thing blocks seem to be able to do that C++11 lambdas do not is that multiple blocks are able to share mutable data (which at least makes the decision to make __block a storage class not stupid).

As for the type erasure, a block is pragmatically an instance of NSBlock, which is represented as "?" in the type signature and is morally equivalent to an object id. There is therefore an implicit conversion from blocks of all types to id.

Meanwhile, even in C++, there is an implicit conversion from id to blocks of any type signature. As blocks are objects and objects often need to be smuggled around, this leads to messy and non-obvious type conversions in programs that use them.

From a language design perspective, this fails to take into consideration the history of Objective-C; while object type casting in Objective-C is sloppy, selectors are supposed to fairly uniquely map to a specific type signature.

The reason this is important is that if you have a random object, you want to be able to send it an arbitrary message and not be concerned you got the type signature wrong; the worst that can happen is that the object doesn't understand.

However, blocks mix together the concept of invocation with selectors both physically (you can even send it an invoke message) and conceptually (as you can think of the call as a special selection syntax) and yet break this type guarantee.

Even worse, blocks didn't even have their type encoded at all when they were first designed, so in addition to this being awkward at compile time, it was even fundamentally impossible to catch this kind of type error at runtime.

Thankfully, they fixed that (although now blocks compiled with older compilers, which I believe Apple simply counts gcc in its entirety as these days, won't have this information), but they did not also solve any of the other type issues.

> C++11 supports mutable lambdas. The only thing blocks seem to be able to do that C++11 lambdas do not is that multiple blocks are able to share mutable data

Blocks are also a bit simpler if you want to continue to mutate the same variable both inside and outside of a lambda (but then have the variable stay alive after the outer function exits).

> As for the type erasure, a block is pragmatically an instance of NSBlock, which is represented as "?" in the type signature and is morally equivalent to an object id. There is therefore an implicit conversion from blocks of all types to id.

All objects are also represented with the same character, and all function pointers are ^?. This may be unfortunate, but isn't really about blocks; in pure C, of course, they are only erased inasmuch as all types are erased.

> The reason this is important is that if you have a random object, you want to be able to send it an arbitrary message and not be concerned you got the type signature wrong; the worst that can happen is that the object doesn't understand.

How do you mean? If you have a random `id`, or possibly an object casted to the wrong object type (isn't that the equivalent scenario, since you're talking about implicit casting from id to blocks of any type signature?) and send it a message for a selector it implements but with different types, the call will go through and probably crash, same as if you cast a block to the wrong type.

> ...and send it a message for a selector it implements but with different types...

I am not certain how to best correct the misconception here. Yes: if you do this, it will crash. However, as I stated, the history of this language sets us up so that this should not happen: a selector should uniquely identify a calling signature to the best of the abilities of the programmers involved (and generally it will by accident for anything but very short names).

The reality is that this is actually not just convenient but somewhat required, as the compiler has to select a specific calling convention at compile time, so if you are using an object in a situation where it is even remotely ambiguous you get a compiler diagnostic if there is any ambiguity in the libraries you are working with with respect to the selector's type signature.

Again, with blocks, this all breaks: you can't even get a warning, because the user has to cast it first to a specific calling convention, and it isn't obvious in the code, because the cast is allowed to be implicit. The chance of an overlap is high, because the conceptual selector's name is effectively nothing. Objective-C mitigates this problem elsewhere: not here.

> All objects are also represented with the same character, and all function pointers are ^?. This may be unfortunate, but isn't really about blocks; in pure C, of course, they are only erased inasmuch as all types are erased.

A) It is not relevant that the class of an object is erased, because what's important is the type of a message implementation: you don't break the type system by having an object of the wrong class, only by sending a message with the wrong calling convention. It doesn't matter at all, therefore, whether objects are all "erased": there wasn't information there to begin with.

B) It is not relevant that C function pointers have their type erased, because they aren't also objects: the whole point of objects in Objective-C is that they are dynamically typed (back to point A: their type is irrelevant), so you are expected to use them as arguments to things like withObject: and then let them implicitly cast back on the other side. Again: selectors are king.

C) It is not relevant that in pure C types are "erased" as C does not have a runtime, so I'm not even certain how one could determine the difference between the types being erased and the types not being erased. The erasure wasn't even the core problem, remember: the erasure only makes it impossible to have runtime fixes for the actual problem, which is the compile-time selector slop.

> However, as I stated, the history of this language sets us up so that this should not happen: a selector should uniquely identify a calling signature to the best of the abilities of the programmers involved (and generally it will by accident for anything but very short names).

I see what you're saying... screwing up an id cast will usually not cause low-level indeterminacy (even though it might), but screwing up a block cast always will. This seems like a pretty minor issue to me, especially as blocks usually need not be passed as ids in the first place, and Objective-C is hardly a safe language in other respects (at least historically, with retain/release).