<div dir="ltr"><div dir="ltr">On Sun, May 3, 2020 at 9:10 PM Panke via Digitalmars-d <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sunday, 3 May 2020 at 10:52:37 UTC, Stefan Koch wrote:<br>
><br>
> If there are any other open questions about how this is <br>
> supposed to work I am happy to answer them.<br>
<br>
I think type functions are important work.<br>
<br>
What operations are available on types? Can I do something like <br>
this:<br>
<br>
---<br>
TStruct structFromSpec(string spec)<br>
{<br>
     TStruct result;<br>
     for (field; parseFields(spec))<br>
     {<br>
         result.addField(<a href="http://field.name" rel="noreferrer" target="_blank">field.name</a>, field.type)?<br>
     }<br>
     return result;<br>
}<br>
---<br>
<br>
or how is it supposed to look? I'd figure compile times will be <br>
improved greatly at first and suffer heavily afterwards, because <br>
everyone will be using this awesome feature to do even more at <br>
compile time.<br>
<br>
Is there any plan to cache the results of type functions? What do <br>
we need to incorporate into the design to make it cacheable?<br>
<br>
<br>
I am eager to see this in action.<br></blockquote><div><br></div><div>Doing "even more" at compile time is not a bad thing, and should actually be perfectly natural.</div><div>The problem we have today is that recursive instantiation is often N^2, and also very expensive in terms of symbol mangling, and populating the symbol tables with gigabytes of junk.</div><div><br></div><div>If you remove the N^2-ness and also remove gigabytes of rubbish from the compiler, you can do immensely more then we do now, and still not experience comparable slow-ness to what we experience today.</div></div></div>