__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