---------- Forwarded message ---------
From: Torben Thaysen <thaysentorben_at_[hidden]>
Date: Fri, Mar 4, 2022 at 2:53 PM
Subject: Re: [std-proposals] A new kind variable for immediate functions
To: <marcinjaczewski86_at_[hidden]>


I think this should be fixed a bit diffrent way. Current `constexpr`
> variables can materialize in result code and this is problem if we use
> memory allocation.
>
I am not sure what you mean. The way I understand it, whether you find some
trace of constexpr variables in the final binary/assembly
(or whether they are "materialized") is decided by the compiler the same
way as for any other (inline) variable. Since what I am proposing is
a local variable inside of immediate functions, the only place they could
"materialize" is into the body of that function, which by definition doesn't
exist at runtime.
When you try something like

consteval const int* leak_ptr() {
    consteval int i = 1;
    return &i;
}
int main() {
    constexpr auto ptr = leak_ptr();
}

the local variable won't "materialize", instead you would get a compiler
error since a pointer to an object of automatic storage duration is not
allowed in a constant expression.

One way I could see to fix it make option for "pure" `constexpr
> variables that only live during compilation and are not accessible in
> anyway by run time.
>
This sounds quite similar to what I proposed but with the requirement to be
in an immediate function removed. This might have the advantage
that it could save you from having to define an extra function. However
consider that with your version you are restricted to the initializer of
result
variable, which means that when the constructor you mentioned doesn't exist
or you want to do something more complicated the just copy some data,
you would have to write a helper function anyways.

Marcin Jaczewski <marcinjaczewski86_at_[hidden]>:

> pt., 4 mar 2022 o 12:54 Torben Thaysen via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
> >
> > Currently when computing things at compile time one sometimes faces a
> problem when trying to output the result to a constexpr variable.
> > This happens when the result is data structure without a fixed size that
> utilizes dynamic memory allocation, which in itself is not a
> > constant expression (for example a vector). Today the result can be
> converted to a more appropriate fixed sized structure like this:
> >
> > constexpr std::vector<int> compute_vector();
> > constexpr std::size_t extract_size() { return compute_vector().size(); }
> > constexpr auto as_array() {
> > auto vec = compute_vector();
> > std::array<int, extract_size()> arr;
> > std::copy(vec.begin(), vec.end(), arr.begin());
> > return arr;
> > }
> >
> > But this somewhat awkwardly involves doing the computation twice. The
> only way around this is to copy the data to a large intermediate array
> > then copy it again into an array of the right size. Neither of these
> solutions is really ideal and that is what this proposal aims to solve.
> >
> > For this I want to introduce a new kind of variable that can be declared
> inside an immediate function. With this the above example could look like:
> >
> > constexpr std::vector<int> compute_vector();
> > consteval auto as_array() {
> > consteval auto vec = compute_vector(); // example syntax
> > std::array<int, vec.size()> arr;
> > std::copy(vec.begin(), vec.end(), arr.begin());
> > return arr;
> > }
> >
> > The requirements for this type of variable should conceptually be
> similar to those for constexpr variables (see 9.2.6.10 and 7.7.11) except
> that:
> >
> > Targets of pointers and references don't have to have static storage
> duration. In particular pointers to dynamically allocated memory are
> allowed.
> > Memory allocations performed in the initialization can (and must) be
> deallocated in the destructor.
> > And (i think) pointers to immediate functions can also be allowed, since
> this type of variable only exists inside immediate functions. Although this
> > isn't required for the aim of this proposal.
> >
> > To my reading this lifts all the requirements of 7.7.11 so that any core
> constant expression with the modified allocation requirement would be
> allowed.
> > Like with constexpr variables these new variables should also be implied
> to be const. And I propose for consistency they should be allowed to be
> > declared in any immediate function context as by 7.7.13 (i.e. also
> inside a if consteval statement).
> >
> > Looking forward to your feedback
> > Torben
> >
> > --
> > Std-Proposals mailing list
> > Std-Proposals_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> I think this should be fixed a bit diffrent way. Current `constexpr`
> variables can materialize in result code and this is problem if we use
> memory allocation.
> One way I could see to fix it make option for "pure" `constexpr
> variables that only live during compilation and are not accessible in
> anyway by run time.
> This way we could make:
> ```
> int main() //can be used in any function!
> {
> consteval auto s1 = std::string("Test"); //variable and memory
> allocation live only during "compilation" of `main`, we could consider
> this a new `static` in some way.
> static constexpr std::array<int, s1.size()> a1 = { s1.begin(),
> s1.end() }; //assume that array have constructor that can copy from
> range
>
> auto s2 = std::string(s1); //Error! `s1` is not accessible here!
> auto s3 = std::string(a1.begin(), a1.end()); //normal string that
> copy data from static memory
> }
> ```
>