Ambiguity issue with expanding and evaluating single template type parameter enums

Paul Backus snarwin at
Tue Dec 28 00:57:27 UTC 2021

On Tuesday, 28 December 2021 at 00:42:18 UTC, data pulverizer 
> On Tuesday, 28 December 2021 at 00:32:03 UTC, Paul Backus wrote:
>> In this case, the simplest solution is to have your code 
>> generator accept a string as its input, rather than a type. 
>> For example:
>> ```d
>> enum instantiate(string type, string expr) = type ~ "(" ~ expr 
>> ~ ")";
>> pragma(msg, instantiate!("RVector!(SEXPTYPE.REALSXP)", "x"));
>> ```
> Well the code needs to be responsive from parameter types `T` 
> generated from other code. I'm allowing the user to create 
> functions select those they wish to access in R by UDA 
> decorators in the D script which I then filter for and wrap the 
> necessary functions generating any type conversion code I need 
> at compile time to create functions callable in R.

I see. So, you need access to the type as a type in order to 
reflect on it, but you also want it as a string in order to 
generate code.

My guess is that you don't actually *need* to use string mixins 
for most of this, but I can't say for sure without seeing a more 
complete example.

More information about the Digitalmars-d-learn mailing list