Are we on the simplest path for working with compile time entities?

[Avrina]

On Friday, 25 September 2020 at 09:37:23 UTC, Stefan Koch wrote:
> Hi,
>
> If you'll remember I recently talked about an alternative way 
> of implementing working with compile time entities such as 
> types.
>
> And I was pleased about it getting attention from prominent 
> forum members and even Walter.
>
> I gave the example of using a static map function to get the 
> type sizes of a tuple of types.
>
> As a result Walters does adds the ability to get sizeof without 
> having to interface with the type entities :
> The code for just that functionality to be added is this:
>
>                             if (fd.ident == Id.tsize)
>                             {
>                                 // Equivalent logic to 
> `T.sizeof` in getProperty()
>                                 d_uns64 sz = t.size(dve.loc);
>                                 if (sz != SIZE_INVALID)
>                                 {
>                                     ret = new 
> IntegerExp(dve.loc, sz, Type.tsize_t);
>                                     return;
>                                 }
>                             }
>
> Is that what we want for every property of typeid ?
>
> How many properties do we need to add to typeid to make it 
> really usable?
> UDAs?
> vtbls?
> member names?
> offsets?
>
> Can I get the fully qualified name from this?

I'm not particularly fond of either approach. Saying you can 
optimize recursive templates, if it was that simple it would have 
already been done. I don't see being it being optimized unless 
the entire compiler was gutted, but that comes with its own 
problems.

Type functions, I really don't like the syntax of how it is just 
passing a type like a regular function. It adds syntax that is 
the same as what is already there but does something completely 
different. It adds too much complexity while pretty much 
replacing something without it being actually removing what's 
already there.

For the most part what is needed is "T...", just to be able to 
manipulate it with an interface that aren't templates. Basically 
a type that can only be used at compile time but can be anything, 
like "T...".

It is basically a subset of what type functions would be, without 
adding a whole new way to call functions.

Note `alias[]` is just a placeholder.

auto static_map(alias F, T...)()
{
     alias[] result;
     result.length = T.length;

     foreach(i, t; T)
     {
         result[i] = F!t();
     }

     return result;
}

size_t sizeOf(alias t)
{
     return t.sizeof;
}

static assert(static_map!(sizeOf, int, ushort) == [4, 2]);


There are some problems though, like how to add a type to the 
array, currently you can't use say, "result ~= int". It looks 
odd, and it has to be compile time compatible. As it would be a 
special type, it could be ignored or lowered to "opAssign!("~", 
RHS)" instead to ensure it can be calculated at CT.

Then you would be able to do something like this:


   alias[] result;
   result ~= int;
   result ~= 10;

   result[0] v = result[1]; // equivalent to `int v = 10`

Right now to do something similar you would have to instantiate 
templates.

   alias first = AliasSeq!(int);
   alias result = AliasSeq!(first, 10);

   result[0] v = result[1];

Because you need templates to express the same thing, where you 
can't use one template, you have to use a new template to define 
it. This is what results in requiring recursive templates that 
expands into more and more templates. This is really all that's 
needed to simplify what is currently being done. We just need a 
way to define a template-like generic object ('T...') as a 
variable instead. The compiler implementation it would just be an 
array that's manipulated at compile time with information it 
already has.

The details need to be ironed out but I feel this is a more 
natural inclusion, it's taking what's already there and just 
allowing you to use it without having to define a template.