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
>