>1) I expect that it would be viewed from within each compiled function.
(Note the recursion concern above.)
I'm not sure I get that. If the compiler does not have access to the
definitions, how will it execute any instructions related to the "consteval
state" in the client code?
>2) That would be determined by how the caller calls it.
I think that a symbolic executer would declare the result as having two
possible states, or alternatively the design could requires the states of X
and Y to be the same.
>3) I'd expect that it would be the same as a constexpr dynamic array,
unless I'm misunderstanding the question?
The question can be rephrased as "what is the consteval state of an object
that was retrieved from a dynamic container (eg not a static array)?"
The compiler can't keep track of what is going on in a vector, much less a
hashmap and more complex container. A potential alternative is to say that
the state is undefined and the user must guarantee the consteval state of
an object before using any functions relying on it.

Basically the fact that the compiler does not see the whole code is already
a large obstacle, and then there's a dozen other problems to tackle.

In your specific example I would just make the methods return a different
type corresponding to each specific state, since you don't need to
"destructively move" the object into each operation.

Le lun. 9 août 2021 à 22:49, Scott Michaud via Std-Discussion <
std-discussion_at_[hidden]> a écrit :

> Good questions.
>
> Note that I am not a compiler engineer -- a compiler engineer would be in
> a much better position to comment on feasibility, and possibly suggest
> alternatives.
>
> That said...
>
> I personally cannot see a way that this feature would be used for more
> than just affecting how functions are generated. Everything would be
> anchored as a function local or a private class member of an object
> instance that's local to a function. If we assume that everything is local
> or a private class member of an object instance that's local to a function,
> then it should untangle in the same way as inlining. My main concern is
> recursion, but there might be a simple constraint to untangle that.
>
> Public and protected class members are also a concern. If those are
> allowed, then I would expect that extra metadata would need to be emitted
> by the compiler, leaning on the linker to strip it out when it produces a
> binary. That may not be a concern with modules, however. I am not sure.
>
> ... So in terms of the specific questions:
>
> 1) I expect that it would be viewed from within each compiled function.
> (Note the recursion concern above.)
>
> 2) That would be determined by how the caller calls it.
>
> 3) I'd expect that it would be the same as a constexpr dynamic array,
> unless I'm misunderstanding the question?
>
>
>
> On 8/9/2021 9:53 AM, Jean-Baptiste Vallon Hoarau via Std-Discussion wrote:
>
> Hi,
>
> The idea of attaching custom data at compile time for program verification
> is good (often referred to as "typestate") however it comes with some
> difficult questions :
> * in C++ the whole program is not accessible to the compiler, what should
> be the syntax for mutating a state in a function header?
> * how to handle references and pointers : two objects X and Y are passed
> in a function F which can return a reference to either, how is this
> expressed in the function header, and what is the resulting state of the
> reference?
> * what is the state of an object obtained from a dynamic array?
>
> Le dim. 8 août 2021 à 21:39, Ville Voutilainen via Std-Discussion <
> std-discussion_at_[hidden]> a écrit :
>
>> On Sun, 8 Aug 2021 at 22:08, Scott Michaud via Std-Discussion
>> <std-discussion_at_[hidden]> wrote:
>> >
>> > I had a random thought while drinking my Friday coffee. This is not a
>> proposal. I discussed it on a C++ Discord, but it was met with criticism.
>> That said, sometimes even the biggest failures can lead to interesting
>> successes, so I'm curious what the std-discussion list thinks about it.
>> >
>> > The concept is compile-time data, which I'm calling "consteval
>> members". Its goal is to simplify some of the situations where templates
>> and macros are abused by letting people express their intent in a more
>> literal, OOP fashion using data that the compiler cannot allow in the
>> actual assembly. This can be used as better control flow based on the
>> specific value of literals, and it can be used for better compile-time
>> error handling.
>> >
>> > The key is that the transforms must happen at compile-time. The
>> consteval data cannot be in the application at runtime.
>> >
>> > Some concerns:
>> >
>> > I expect that this would be horrifyingly painful to implement in an
>> actual C++ compiler.
>> > This might be difficult for debuggers to implement... although I'd
>> expect it would be able to infer the consteval state from the source code.
>> >
>> > On the plus side, I also believe that it allows very readable and
>> maintainable code, especially for library authors that hide its usage with
>> access specifiers, so it might lead into some interesting ideas.
>> >
>> > This email will show a use case where a factory-style object collects
>> properties and produces an object instance ("the builder pattern"). This
>> mechanism will allow the various functions to guide the user (with compiler
>> errors) if they forgot required data, or if they set incompatible
>> properties. In this case, the user must supply an IP address and a port,
>> but they are allowed to choose any mechanism that does that, and (in this
>> example) they can do so in any order (although another use case could
>> easily check for order).
>>
>> This sure looks like something that falls under the general umbrella
>> of compile-time side effects and mutations.
>> We'll perhaps get there once we get the more urgent bits of
>> https://wg21.link/p2237 off the ground and into the standard.
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>>
>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>