Yeah, I'm not sure how much constraints would be required before it
boils down to problems that are within the domain of the compiler and
the linker. Thanks for the thoughtful replies!


On 8/9/2021 5:42 PM, Jean-Baptiste Vallon Hoarau via Std-Discussion wrote:
> >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]
> <mailto: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]
>> <mailto:std-discussion_at_[hidden]>> a écrit :
>>
>> On Sun, 8 Aug 2021 at 22:08, Scott Michaud via Std-Discussion
>> <std-discussion_at_[hidden]
>> <mailto: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 <https://wg21.link/p2237> off the
>> ground and into the standard.
>> --
>> Std-Discussion mailing list
>> Std-Discussion_at_[hidden]
>> <mailto:Std-Discussion_at_[hidden]>
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
>> <https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion>
>>
>>
> --
> Std-Discussion mailing list
> Std-Discussion_at_[hidden]
> <mailto:Std-Discussion_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion
> <https://lists.isocpp.org/mailman/listinfo.cgi/std-discussion>
>
>