C++ Logo

std-proposals

Advanced search

Re: [std-proposals] consteval variables

From: Jarrad Waterloo <descender76_at_[hidden]>
Date: Wed, 31 Jul 2024 07:12:41 -0400
Sorry, forgot to attach slides.



On Wed, Jul 31, 2024 at 7:09 AM Jarrad Waterloo <descender76_at_[hidden]>
wrote:

> 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
>>
>

Received on 2024-07-31 11:12:54