On Wed, Apr 03, 2024 at 09:34:29AM -0500, Barry Revzin via Std-Discussion wrote:
>On Wed, Apr 3, 2024, 9:09 AM Tiago Freire via Std-Discussion <
>std-discussion_at_[hidden]> wrote:
>
>> > You might have also misinterpreted my mail.
>> > I'm not asking if it is possible to do it with variables, I already know
>> it is possible.
>> > The question is if something similar was considered for functions,
>> because there are similar advantages.
>>
>> Sorry if I have misunderstood your email.
>>
>> That it works for variables is already a stretch of the language.
>> And this only works if the .cpp file that declares
>> constexpr int myconstant;
>> sees
>> extern const int myconstant;
>>
>> otherwise, it doesn't work.

You can write

// header file
extern const int myconstant;


// in cpp file without including header
extern constexpr int myconstant = 42;

>> It can't for the exact same reasons. The compiler wouldn't know.
>> But in the function case there's a far more elegant solution that
>> satisfies what you want to do.
>>
>> Have you tried
>>
>> int function() { return function_constexpr(); }
>> ?
>>
>> Because you can just do that, and has exactly the same properties, except
>> for preserving the name.
>>
>
>
>Yes, the original post is very clear that he tried that. He explicitly
>listed the shortcomings of that approach.

Exactly, it is a workaround, with different shortcomings.
There is nothing elegant to duplicate function signatures and forward
all parameters.

>But the point still stands, cpp modules will fix this.

I was not aware that module would give that flexibility.

If it is the case, then I assume that proposing such a change would be
of limited interest, unless there are some scenarios where modules are
not a viable alternative (legacy could be one, we are still maintaining
the non-range algorithms).

>> You could make a proposal to make this work in the interim.
>>
>> And I don't think there's going to be an appetite for this given that:
>> a) modules will fix it
>> b) there's a trivial work around
>> c) right now compilers don't have to emit code if they are not used, and
>> they would have too as a consequence
>> d) the use of it would be quite limited to justify the work
>>

The solution for c) would be using an unnamed namespace to tell the
compiler that a function is only used in the current translation unit.
Otherwise "just" like any other unused function, the compiler/linker can
remove dead code.
It's consteval that generally does not emit any code, as constexpr can
be used at runtime too, the compile "must" generate code for it like
other functions.

>While I agree with (d), I'm not sure what about modules "fix" this? You
>could still, in a module, want to export the signature and in an
>implementation unit it define it as constexpr and use it as such in that
>specific translation unit.

I'm having difficulties to understand this part.
If modules support it, there is no work to be done (for modules).

>> The idea is sound, not entirely sure if anyone else has proposed this
>> before (someone else can comment on that).
>> But I wouldn't be surprised if it hasn't because of the above.