Can we make mixin applications first class at the type level?

[sighoya]

On Thursday, 21 March 2019 at 09:07:03 UTC, FeepingCreature wrote:
> I have no idea what you are trying to achieve, but I am willing 
> to bet putting a type in a string is the wrong way to do it.
>
> Why don't you give an example of what *outcome* you are trying 
> to achieve first, maybe in a language you are more familiar 
> with, and then we can tell you how to do it in D.

Thanks for your open-heartedness.

My intention is to allow type calculus. For this you would 
normally need first class types, i.e. types as values:

Type type = int;

which is not possible in D and may never be. But there is the 
possibility to model it over mixins if the parser would allow us 
to do so.

For instance a tuple constructor:

*(Type type1, Type type2, Type type3)=(type1,type2,type3)

could be modeled with:

mixin template stringToType(String s)
{
    s
}

*(String type1, String type2, String 
type3)=(stringToType!type1,stringToType!type1,stringToType!type1)


The idea in general is to generate structures generically over 
computed types:

mixin template mapType(Map!(String,String) 
typeToTypeMapping,String selectedType)
{
const char[] s= typeToTypeMapping[selectedType];
}

struct S(T,S)
{
    T t;
    S s;
}

Map!(String,String) mapping= {"Int"=>"String", "String"=>"Char"}
S!(mapType!(mapping,"Int"),mapType!(mapping,"String")) s;

Of course we could simply write the complete struct S as string 
mixin, but most existing code isn't saved in this format because 
string mixins suck (no syntax highlighting).

So allowing mixin expansion in type positions would allow to 
integrate with existing code better in this manner.

It would be that easy if we weren't forced to apply mixins with 
the mixin keyword, why the hell we need to if we annotate our 
template with mixin.

Then ComputetType!String would be parsed correctly by the 
parser.Otherwise wee need to allow (mixin ComputedType)!String by 
changing the grammar.