Discussion on static reflection syntax in C++

Max Haughton maxhaton at gmail.com
Tue Feb 23 06:01:22 UTC 2021


On Tuesday, 23 February 2021 at 05:17:04 UTC, Bruce Carneal wrote:
> On Monday, 22 February 2021 at 23:44:45 UTC, Paul Backus wrote:
>>
>> As far as I'm concerned, a procedural macro is a function that
>>
>> 1. runs at compile time,
>> 2. takes AST nodes as input, and
>> 3. produces AST nodes as output.
>>
>> Type functions fit those criteria perfectly. Currently, they 
>> only work on a subset of AST nodes (types), so they're not a 
>> *complete* implementation of procedural macros, but generalize 
>> them enough and that's what you'll get.
>
> Yes.
>
> Given the collective experience that we've had with D's meta 
> programming facilities it would be surprising if we could not 
> imagine something significantly better at this point.  By 
> "better" I mostly mean facilities that would allow us to write 
> code that is more readable, more composable, more testable, and 
> more easily debuggable than an equally performant solution 
> using current practice.
>
> I'm sympathetic to both type functions and MTVs (monadic type 
> variables), CT type objects with actual memory footprint that 
> function as compiler-guaranteed-safe cursors within the lazily 
> realized dependent type space of a D program.
>
> Beyond those two I know that Stefan, and from the above and 
> earlier writings I expect Paul, have thought about more 
> powerful yet still tractable capabilities.  It feels like we're 
> within reach of a significant advance.

I have been talking to Stefan quite a lot about typefunctions 
recently, I'm reasonably convinced they are the most natural 
proposal to explore for D at the moment.

One thing I have been toying with is calling them metafunctions 
instead since they clearly don't only consider types in the 
general case.


Having a well defined type hierarchy to represent the AST in a 
manner seperate to the actual compiler has an added benefit of 
making it trivial to write clean programs that analyse D code 
without bringing in the entire compiler or going without sema.


More information about the Digitalmars-d mailing list