Date: Fri, 25 Oct 2024 07:55:51 +0200
On Fri, Oct 25, 2024 at 4:16 AM Herb Sutter via SG15 <sg15_at_[hidden]>
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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>
Received on 2024-10-25 05:56:15