__Symbol an alternative to recursive templates for type-introsecption

Jacob Carlborg via Digitalmars-d digitalmars-d at puremagic.com
Sun Oct 9 06:40:14 PDT 2016


On 2016-10-09 05:05, Stefan Koch wrote:
> Hi Guys,
>
> You might remember my critique regarding the fullyQulifiedName-template
> in phobos.
> Basically it is dramatically slowed down by the cost of template
> instanciation.
> I tried to remedy the situation by using by introducing another __trait.
> While this succeeded in reducing the compile-time drastically,
> It was deemed a bad precedent to replace library functionality with
> compiler intrinsics.
>
> If we were to introduce a new that could hold a symbol.
> (akin to AliasSeq!(...)[0]), only much less expensive :))
> Then we could replace the fqn template with this :
>
> template fqn(alias T)
> {
>   string fqn = ()
>   {
>     string result = (cast(__Symbol)T).name;
>     __Symbol t = cast(__Symbol)T;
>     __Symbol p = t.parent;
>     while(p)
>     {
>       result = p.name ~ "." ~ result;
>       t = p;
>     }
>     return result
>   }();
> }
>
> As you can see there is only CTFE and no recursive template instanciation.
> Thereby the currently worst factor would be removed.
>
> The pseudo-type __Symbol is only valid at CT.
>
> It can only be obtained by either a TemplateAliasParameter or from a
> member-variable of another __Symbol.
>
> So far it can be visualized as
> struct __Symbol
> {
>   string name;
>   __Symbol parent;
>   /* MaybeLater:
>   __SymbolType type;
>   __Symbol[] members;
>   ....
>  */
> }
>
>

How about we just implement AST macros and be done with it :)

-- 
/Jacob Carlborg


More information about the Digitalmars-d mailing list