Date: Mon, 31 Jan 2022 17:10:46 -0500
> On Jan 30, 2022, at 7:55 AM, Jonathan O'Connor via SG7 <sg7_at_[hidden]> wrote:
>
> Hi,
>
> Here are some remarks on code generation and extending the splicing operator. I presume both are out of scope for the paper.
Not necessarily, but the paper does intentionally not include “code injection”. That’s not because we don’t want it, but because we think that’s a whole feature of its own (see P1717 and P2237, which build that on top of an earlier version of P1240).
>
> ## Generating classes
> In the future, I would like to be able to define classes and functions, based on some `std::meta::info`.
> As processing of an `info` has to happen inside a function, so it needs to look like the following:
>
> ```c++
> template<typename T>
> auto makeClass() {
> // some magic here to define a class based on T.
> return GeneratedClass{};
> }
>
> template<typename T>
> using generatedClass = decltype(makeClass<T>());
> ```
>
> C++ could support AOP (Aspect Oriented Programming) if we could do this.
> I presume this is out of scope for R1240.
Right: See above. It’s out of scope for P1240 in the sense that that paper will not propose it. It’s not out-of-scope in the sense that the work of P1240 is cognizant of work that enables it. In particular, reflections could represent fragments-to-be-injected (in the future).
>
> ## Splicing operator
>
> Has any thought gone into extending what the splicing construct can do? Could it be
> extended to allow creation of new symbols? If the splicing construct only takes
> a reflection, then that restricts its utility.
Yes, see the subsection titled “Splicing identifiers”. Earlier versions of this paper did in fact propose such a capability. However, once we implemented it we found it raises some questions that require more experience and perhaps an alternative design. So, we have dropped it from P1240, but we still intend to pursue that capability (and also more general code injection).
Daveed
>
>
> Regards,
> Jonathan
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Saturday, January 15th, 2022 at 17:41, Daveed Vandevoorde via SG7 <sg7_at_[hidden]> wrote:
>
>> SG7 mailing list
>>
>> SG7_at_[hidden]
>>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>
> Hi,
>
> Here are some remarks on code generation and extending the splicing operator. I presume both are out of scope for the paper.
Not necessarily, but the paper does intentionally not include “code injection”. That’s not because we don’t want it, but because we think that’s a whole feature of its own (see P1717 and P2237, which build that on top of an earlier version of P1240).
>
> ## Generating classes
> In the future, I would like to be able to define classes and functions, based on some `std::meta::info`.
> As processing of an `info` has to happen inside a function, so it needs to look like the following:
>
> ```c++
> template<typename T>
> auto makeClass() {
> // some magic here to define a class based on T.
> return GeneratedClass{};
> }
>
> template<typename T>
> using generatedClass = decltype(makeClass<T>());
> ```
>
> C++ could support AOP (Aspect Oriented Programming) if we could do this.
> I presume this is out of scope for R1240.
Right: See above. It’s out of scope for P1240 in the sense that that paper will not propose it. It’s not out-of-scope in the sense that the work of P1240 is cognizant of work that enables it. In particular, reflections could represent fragments-to-be-injected (in the future).
>
> ## Splicing operator
>
> Has any thought gone into extending what the splicing construct can do? Could it be
> extended to allow creation of new symbols? If the splicing construct only takes
> a reflection, then that restricts its utility.
Yes, see the subsection titled “Splicing identifiers”. Earlier versions of this paper did in fact propose such a capability. However, once we implemented it we found it raises some questions that require more experience and perhaps an alternative design. So, we have dropped it from P1240, but we still intend to pursue that capability (and also more general code injection).
Daveed
>
>
> Regards,
> Jonathan
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On Saturday, January 15th, 2022 at 17:41, Daveed Vandevoorde via SG7 <sg7_at_[hidden]> wrote:
>
>> SG7 mailing list
>>
>> SG7_at_[hidden]
>>
>> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
Received on 2022-01-31 22:10:48