Ross Bencina
Ross Bencina

Reputation: 4173

C++20: Non-capturing lambda in non-type template parameter

Does C++20 allow a non-capturing lambda decayed to a function pointer to be passed directly as a non-type template parameter? If so, what is the correct syntax?

I have tried the following code in various versions of clang and gcc using -std=c++2a.

#include <iostream>

template<auto f>
struct S {
    static void invoke(int x) { f(x); }
};

using X = S<+[](int x) -> void { std::cout << x << " hello\n"; }>;

int main()
{
    X::invoke(42);
}

gcc compiles the code without complaint and the code runs as expected.

clang fails compilation with the following error:

error: a lambda expression cannot appear in this context
using X = S<+[](int x) -> void { std::cout << x << " hello\n"; }>;
             ^

Here is the full code (online versions):

Clang 10.0.0 HEAD: https://wandbox.org/permlink/n5eKQ4kQqSpDpr4k

Gcc 10.0.0 HEAD 20200113: https://wandbox.org/permlink/vJ44sdMtwCKAFU64

Upvotes: 10

Views: 1184

Answers (3)

Barry
Barry

Reputation: 302757

Does C++20 allow a non-capturing lambda decayed to a function pointer to be passed directly as a non-type template parameter?

Yes.

Indeed, you can go one step further - you don't even need to convert the lambda to a function pointer. You can just provide the lambda. This is valid C++20:

using Y = S<[](int x) -> void { std::cout << x << " hello\n"; }>;

Sorry this is no longer considered valid C++20, since CWG 2542, lambdas are not "structural" types (the term for which types are usable as non-type template parameter types).


The rule we have in C++20 is that lambdas are now allowed in unevaluated contexts (P0315). Among many other wording changes there, this paper struck the rule that prevented lambdas from being used in template arguments (C++17's [expr.prim.lambda]/2):

A lambda-expression shall not appear in an unevaluated operand, in a template-argument, in an alias-declaration, in a typedef declaration, or in the declaration of a function or function template outside its function body and default arguments.

That clause does not exist anymore in C++20.

Removing this restriction allows the lambda to be used as a template argument, and the conversion from captureless lambda to function pointer was already constexpr in C++17. clang simply does not implement this feature yet (using T = decltype([]{}); compiles on gcc, not yet on clang). I wouldn't call this a clang bug yet, it's just a clang not-yet-implemented-feature (lambdas in unevaluated contexts is not yet listed as implemented in the cppreference compiler support page).


C++20 non-type template parameters (P1907) allows even dropping the + because captureless lambdas count as structural types ([temp.param]/7) by way of simply not having any data members at all.

Upvotes: 11

Indiana Kernick
Indiana Kernick

Reputation: 5331

If the rules on this haven't changed since C++17 then using a lambda as a template parameter is not allowed for the same reason that using a string literal is not allowed. Every lambda has a different type and every string literal refers to a different object. What changed in C++17 is that closure objects are now constexpr. To use a string literal or a lambda as a template parameter, the object must have external linkage. So this is allowed in C++17.

template <auto>
struct S {};

constexpr const char string[] = "String literal";
constexpr auto lambda = []{};

S<string> a;
S<+lambda> b;

The closure object itself cannot be used as a template parameter (so you can't do S<lambda>) but this might have changed in C++20 with three-way comparisons. The reason the objects must have external linkage is because it kind of breaks templates. S<+[]{}> and S<+[]{}> would be considered different types even though they look the same (similarly with S<"">).

Upvotes: 0

user2052436
user2052436

Reputation: 4765

Template parameter must be a constexpr variable.

There is a relevant proposal N4487 for lambdas.

I don't know if it made it into C++20.

Upvotes: -2

Related Questions