should lambda to function pointer conversion become constexpr

[frr...@gmail.com]

Hello,

I sometimes use the following pattern:

static const struct {
    const char* name;
    void (*func)(int);
} functions[] = {
     { "function1", [](int) { ... } },
     { "function2", [](int) { ... } },
     ...
};

And when I look at the generated code, I see that this array gets generated at runtime.

Ideally I would like to declare this array constexpr, and that would work if I used named functions, however it does not for lambda, and I cannot see any good reason for that.

As the function pointer conversion operator only exists for state-less lambda, would'nt it make sense to define them as constexpr and their conversion operator as well ?

Cheers,

Maxime Coste.

[Adam Nevraumont]

Yes, it should. This would also allow lambdas to be used as function argument template parameters somewhat.

However nothing in C++ stops that array from being compile time initialized even if it is not constexpr.

[David Krauss]

On 2014–07–17, at 8:46 AM, Adam Nevraumont <a...@theorem.ca> wrote:

Yes, it should.  This would also allow lambdas to be used as function argument template parameters somewhat.

However nothing in C++ stops that array from being compile time initialized even if it is not constexpr.

I agree with the proposal, but

1. Lambda types can be used as template arguments, including lambdas used as arguments to function templates. However, the body of a lambda is never constexpr-qualified, so you won’t be able to parameterize a constexpr higher-order function over lambdas.

2. You never said anything about an array. It sounds like you intended to provide an example,

typedef void (*op_ptr)();

constexpr op_ptr op_table[] = {

[] { std::cout << "hello"; }, // opcode::hello

[] { std::cout << "bye"; }, // opcode::goodbye

[] { done_flag = true; } // opcode::done

}; 

This looks perfectly reasonable.

[Richard Smith]

+1, there doesn't seem to be any good reason not to allow this.

[Gabriel Dos Reis]

It does.

It is sad that we needed to introduce a keyword to get the notion
accepted by the C++ community, and we couldn't just infer
'constexprness' from the (inline) definition and use context.

-- Gaby

[Thiago Macieira]

On Thursday 17 July 2014 17:28:13 Gabriel Dos Reis wrote:
> It is sad that we needed to introduce a keyword to get the notion
> accepted by the C++ community, and we couldn't just infer
> 'constexprness' from the (inline) definition and use context.

I would like to see constexprness inferred from context, but I also appreciate
having the keyword that tells me when I failed to make it constexpr.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358

[Gabriel Dos Reis]

Thiago Macieira <thi...@macieira.org> writes:

| On Thursday 17 July 2014 17:28:13 Gabriel Dos Reis wrote:
| > It is sad that we needed to introduce a keyword to get the notion
| > accepted by the C++ community, and we couldn't just infer
| > 'constexprness' from the (inline) definition and use context.
|
| I would like to see constexprness inferred from context, but I also appreciate
| having the keyword that tells me when I failed to make it constexpr.

I see a distinction between mandatory constexpr and optional constexpr.

As we have been warming up to more compile-time computations, I think it
is becoming clearer and clearer that requiring constexpr is making not
only the code more verbose, but also that failure to repeat
syntactically the semantics information already in possession of the
compiler is making it harder to smoothly develop new programming
techniques and pattern around the language features and standard library
facilities.

-- Gaby