Date: Thu, 24 Oct 2024 19:16:18 -0700
> 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)
Of course, all the usual security controls would need to apply, like sandboxing and controlling what directories can be written to.
Herb
> 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)
Of course, all the usual security controls would need to apply, like sandboxing and controlling what directories can be written to.
Herb
Received on 2024-10-25 02:16:19