Date: Sun, 24 Aug 2025 23:45:25 -0700
> On Aug 24, 2025, at 10:57 PM, Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> One thing that strikes a nerve with me is that if you declare a function inline neither MSVC or GCC actually inline anything, as far as I was able to observe only clang seems to respect the keyword.
> You actually need to use a non-portable compiler specific keyword in order to (pretty please with sugar on top, just freaking do it and) actually get it to do what you want. There's already a keyword that exists in the standard to do this job, and it is complete BS to have to use a different non-portable one to make things work.
“inline” is just a linker directive. Aside from the linkage behavior there is nothing observable about inlining, so if you want to specify that “inline” must inline, then you need to add wording to the standard about how function calls are made, and how they can be observed within the bounds of the abstract machine, so that you can make it observable that a function has been inlined. Doing that will mean debug builds will have to inline as well because it’s now observable within the defined behavior of the abstract machine. This will also require breaking existing code that has self recursive or mutually recursive “inline” functions that cannot be reduced to tail recursion, because those functions can no longer be compiled. There’s also going to be obvious massive increases in codesize and associated performance costs, and likely regressions in compile time but those are as important.
C also has its own, different and weird, definition of inline, but because it’s already different from C++ that’s not a compatibility concern, but presumably you’ll want to change that definition as well.
> I think the standard can be made normative in this regard, as well as offer additional mechanisms that if a function inputs are all constant expressions, the result itself should also be a constant expression.
That sounds like you want consteval? Why not just make your function constexpr?
—Oliver
>
> One thing that strikes a nerve with me is that if you declare a function inline neither MSVC or GCC actually inline anything, as far as I was able to observe only clang seems to respect the keyword.
> You actually need to use a non-portable compiler specific keyword in order to (pretty please with sugar on top, just freaking do it and) actually get it to do what you want. There's already a keyword that exists in the standard to do this job, and it is complete BS to have to use a different non-portable one to make things work.
“inline” is just a linker directive. Aside from the linkage behavior there is nothing observable about inlining, so if you want to specify that “inline” must inline, then you need to add wording to the standard about how function calls are made, and how they can be observed within the bounds of the abstract machine, so that you can make it observable that a function has been inlined. Doing that will mean debug builds will have to inline as well because it’s now observable within the defined behavior of the abstract machine. This will also require breaking existing code that has self recursive or mutually recursive “inline” functions that cannot be reduced to tail recursion, because those functions can no longer be compiled. There’s also going to be obvious massive increases in codesize and associated performance costs, and likely regressions in compile time but those are as important.
C also has its own, different and weird, definition of inline, but because it’s already different from C++ that’s not a compatibility concern, but presumably you’ll want to change that definition as well.
> I think the standard can be made normative in this regard, as well as offer additional mechanisms that if a function inputs are all constant expressions, the result itself should also be a constant expression.
That sounds like you want consteval? Why not just make your function constexpr?
—Oliver
Received on 2025-08-25 06:45:39