Yes, please! It could use a fresh perspective. Also consider consteval
temporaries or in other words, temporaries promoted to be consteval both
explicitly and implicitly.

There is an EWGI meeting on *August 12th (Monday) (15-16:30 UTC, 17-18:30
CEST, 11am EDT, 8am PDT)* to discuss P3218R0
<https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3218r0.html> —
const references to constexpr variables. Please be there.

Zoom link:
https://iso.zoom.us/j/92187414076?pwd=sURAqvCSoyV1a5ObwpdhkIq13ZD1u0.1
(password
is same as for wiki)

Please see related and attached.

constexpr Function Parameters
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1045r1.html

std::constexpr_wrapper
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p2781r4.html

const references to constexpr variables
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3218r0.html

constant dangling
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2724r1.html

variable scope
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2730r1.html

C Dangling Reduction
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2750r2.html

temporary storage class specifiers
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2658r1.html

implicit constant initialization
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2623r2.html























On Wed, Jul 31, 2024 at 4:46 AM Mital Ashok via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> I was thinking about writing a proposal for consteval variables.
>
> They would have similar restrictions as consteval functions: It can
> only be ODR-used in an immediate function context (and ODR-use would
> be immediate escalating).
>
> One advantage is they will not have an address at runtime. So no more
> symbols for a single padding byte for the std::ranges niebloids or
> other `static constexpr` variables.
>
> The main feature is that the destructor of a consteval variable is
> called (at the end of the translation unit or something), allowing a
> transient allocation, e.g., `consteval std::vector<int> x = { 1, 2, 3
> };`.
> `int* p = x.data()` would still be ill-formed because `x.data()` as a
> constant expression points to a transient allocation (which is not a
> permitted result of a constant expression), but `int y = x[0];` would
> be allowed. This would be an alternate solution to the ones proposed
> in P2670R1.
>
> This can already be kind-of implemented with a consteval function, but
> you have to call it every time and compilers are not always good at
> caching consteval function calls (See also:
> <https://github.com/llvm/llvm-project/issues/61425>). Plus, there
> would only be a single object, so:
>
> consteval std::vector<int> var = {1, 2, 3};
> consteval std::vector<int> fn() { return {1, 2, 3}; }
> static_assert(var.data() == var.data());
> static_assert(fn().data() != fn().data());
>
> Would there be any interest in this? Or any related thoughts?
>
> Thanks,
> Mital
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>