Beyond the veil: What's after type functions

[Max Haughton]

On Wednesday, 6 January 2021 at 16:30:25 UTC, Jacob Carlborg 
wrote:
> On 2021-01-04 20:30, Stefan Koch wrote:
>
>> With this in mind, please tell me what you think :)
>
> I think this looks like yet another new set of features just to 
> avoid AST macros. What everyone is currently doing is inventing 
> many highly specialized features just in the name of avoiding 
> AST macros, regardless of the cost.
>
> Instead we could have a very generalized features that would 
> solve a whole bunch of problems and even more problems we 
> haven't thought of yet.
>
> When it comes to the actual API, again, it looks highly 
> specialized for the purpose of the example. It also combines a 
> lot of different language features to do its job, instead of 
> providing a more unified API. Also, I don't like the idea of 
> adding more magic symbols to the compiler, we already have too 
> many of these. D has an excellent module system, but we're not 
> using it. Everything is stuffed into object.d or directly as 
> magic symbols into the compiler.
>
> BTW, the first example is 72 lines. The second is 75 and the 
> last one is 65 (all lines between triple dashes).

I think we should have AST macros but it should be a data 
structure like any other as opposed to how other languages do it. 
We have all this CTFE power so it should just be something like 
the work you began previously.

Typefunctions would be a good demo run for that, as they would 
have to be part of the AST anyway.

I think AST-anything would have to read only to start with.

An API like __traits(getAST, ...) would be fine.