On Fri, Oct 25, 2024 at 4:16 AM Herb Sutter via SG15 <sg15@lists.isocpp.org> wrote:

> Yeah, now that I understand this feature not to be about diagnostics directly
> but about generalized printing at compile time, this makes a lot more sense
> and is something I think our users would find useful.

Yes, thanks!

So that no good deed goes unpunished 😊 I'll warn you that I intend to be greedy: Some of us will be asking for general compile-time I/O, or at least O (output), in a consteval function. For example, to create a file that contains:
JSON
C++ code
another language’s code, such as to generate an FFI binding to call the C++ source (e.g., to emit a .java file that defines a Java `interface` that can be bound to a C++ type)
even binary output files (e.g., .winmd files needed to describe C++ types to the Windows WinRT subsystem, a necessary thing for reflection+generation to replace special/extended compilers needed to generate that for C++ types today)

None of the novel reflection features have deployment experience and a lot of that hasn't been implemented.

As you know, C++20 support is still ongoing and, along with implementing C++23, C23, C++26 and so forth, a lot of resources are going to focus on safety oriented features and improvements.

#embed has just been implemented too, which took a considerable amount of work. Maybe we should also wait to see how people use that.

Besides, the main concern with generating output, is that it throws a wrench in build graphs, so that would need to be designed for by SG15/tooling experts.

Reflection also fails to give a clear model for side effects in constant evaluation in SFINAE context, or how all of that impacts ODR.

Maybe we can take it one step at a time?

Cheers.

Of course, all the usual security controls would need to apply, like sandboxing and controlling what directories can be written to.

Herb

_______________________________________________
SG15 mailing list
SG15@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15