investigate feasability in D

[glathoud]

Reason: performance would be great + mutual recursion syntax then allowed

see also https://github.com/glathoud/fext/tree/master/misc/d_performance_feasability

[glathoud]

Thinking in more details: this must happen at compile time (CTFE). There should be a fallback solution, just throwing around code strings. Probably nicer would be a less intrusive syntax, where most of the code writing would remain "standard", probably something along those lines:

bool isEven( in int n )
{
  return ... mret!isOdd( n-1 ) ...
}

bool isOdd( in int n )
{
   return ... mret!isEven( n-1 ) ...
}

// now we overwrite isEven & isOdd (if D allows that at all!? I guess not? If not => different names)
mixin(mdecl( isEven, isOdd ));

// and for debugging mode... if overwriting possible => just comment out the line, else mdeclD => just aliases 

// +  in all cases, if mret! is actually called, it would be just a pass-through (useful for debugging mode)

whatever exact solution turns out to work, in the less-intrusive case just described, it would be crucial to have access to the function definitions through __traits or std.traits. Is that possible?

[glathoud]

found ParameterIdentifierTuple ParameterStorageClassTuple in std.traits but no access to the function body yet

[glathoud]

looks like this is going to work along those lines:

mixin(fext( q{

bool isOdd( in int n ) {
return ... mret!isEven( n-1 )...
}

bool isEven( in int n ) {
...
}
}));

and mixin(fextD(...)) for debugging.

[glathoud]

For the sake of completeness I asked on a D forum whether one could get a string containing the declaration of a function, answer looks like no, at least not reasonably:
https://forum.dlang.org/thread/clrnrqaotieoilaalswn@forum.dlang.org

[glathoud]

a better place would probably be a new package or module d_glat_common.fext

[glathoud]

future work in glathoud/d_glat#3