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