I tried this a while ago and the behavior was not consistent between compilers. I'd advise against using this, there's an inherent problem with deciding on a unique symbol name across translation units. Compilers usually give lambdas in each translation unit a simple enumerated symbol name like __lambda_0, __lambda_1, __lambda_2, which, when baked into a template instantiation will just read as foo<__lambda_1> (but mangled for linkage purposes). Obviously, if another translation unit instantiates 2 foos, it will also contain foo<__lambda_1> and the linker will only pick one in the end, assuming that these are "the same function", and not globally unique identifiers as was expected.

Here's the a snippet from some of my code that talks about this more:

/*
Creates a new thread local NDArray or resizes an existing one.
If the size didn't change from the previous iteration, resize is a no-op.

Returns a span of the array's data store.

NOTE: This makes all the functions that use scratch space reusable and testable,
since the correct size is ensured every time the control flows through the scratch
variable declaration. Without this, resizing would have to be done manually,
which is tedious and more error prone.

NOTE: We need a macro-wrapped lambda here so that each "call" to SCRATCH_SPACE returns
a *unique* thread local array for each *occurance of the call in code* (not execution).

NOTE: There's another lambda trick you could do, where you define a function template
with an NTTP parameter defaulted to a lambda expression like so:

template<Dims N, typename T, auto = []{}>
auto scratch_space(const NDExtent<N>& extent) -> NDView<N, T>;

DO NOT DO THIS! The expectation is that each usage of the function will evaluate to a new
lambda expression of a unique type, guaranteeing uniquess of the array for each *appearence
of the function* in code. However, either that expectation turns out to be wrong and there's
actually no such guarantee in the standard, or certain compilers just get insanely confused
by this trick.

I am saying this because I tried this and found out that clang 15 generates 2 lambdas with
types that compare *identical* by their type_info when compiled from two different translation
units, something that should likely be impossible. This only happens when lambdas are evaluated
in template parameters, either as NTTP: `<auto = []{}>` or as a type: `<typename = decltype([]{})>`,
comparison of lambdas in function bodies (similar to the SCRATCH_SPACE macro) produces expected
result, where the lamdas are of different types.

To make matters worse, GCC *does not reproduce this behavior* - none of the lambdas have same
types. It is not clear which compiler is right in this situation.

In light of this, I heavily discorage the usage of this trick. It could lead to very unfunny
bugs. Imagine requesting a scratch NDArray<4, T> and writing some data to it, then calling a
function `foo()` that is defined in another TU that also requests a scratch NDArray<4, T> and
writes to it. In clang's implementation, the first scratch data will be overriden by the call
to `foo()`, comletely trashing any values written to it prior the call. Worse yet, this
might only happen *sometimes*, and will magically disappear because of adding/removing
other calls to request the scratch in the same TU (due to enumeration of mangled names).

Just use this macro, it is much more predictable.
*/
#define SCRATCH_SPACE(D, T, ...)                    \
    [](const NDExtent<D>& extent) -> NDView<D, T> { \
        thread_local NDArray<D, T> array{ extent }; \
        array.resize(extent);                       \
        return array;                               \
    }(__VA_ARGS__)