New syntax for string mixins

[Alex_Dovhal]

"Don" <nospam at nospam.com> wrote:
> In order for CTFE code to call pre-compiled code, three things are 
> required:
> (1) the compiler needs to be able to find the file (.obj/.lib/shared 
> library) containing the compiled code;
> (2) the compiler needs to be able to load the module and call it. This 
> requires some form of dynamic linking.
> (3) We need a marshalling step, to convert from compiler literal to 
> compiled data, and back.
>
>
> Step (3) is straightforward. The challenge is step(2), although note that 
> it's a general "allow the compiler to load a plugin" problem, and doesn't 
> have much to do with CTFE.

I thought it over, and got:
(1) can be solved by adding compiler option: --macro-libs=<list_of_libs>, so 
the compiler knows in which dynamic libraries to search for the plugins ;
(2) plugin library functions should be *stdcall*, so C++ compiler can load 
them. That library should implement function like that:

PluginInfo* getFunctionsInfo () ;
where:
typedef struct _PluginInfo{
 struct _PluginInfo * nextPlugin ;
 char* fcnName ; // short name of a function, e.g. "fcn"
 char* params ; // param list, e.g. "(int, float, char*)"
 char* mangledName;//name of funct. in the library, e.g. "_fcn at 12"
 char* returnType ; // e.g. "int"
 bool  isNothrow ; // if useful?
 bool  isPure ;    // ditto
 //... etc ...
} PluginInfo ;

And also should implement all the functions, info about which is returned by 
getFunctionsInfo().
D compiler calls getFunctionsInfo from each plugin library - and then loads 
all the implemented functions with full info about them.
If one plugin function name found in two or more libraries - D throws 
compiler error.
Not a perfect solution, but at least straightforward one and solves given 
problem.

One more note: this approach makes CTFE functions calling such plugins 
uncallable at runtime, which IMO is OK, as one should not call it in any 
case.

Is that suitable?