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;
  ....
 */
}

On Sunday, 9 October 2016 at 03:05:22 UTC, Stefan Koch wrote:
> So far it can be visualized as
> struct __Symbol
> {
>   string name;
>   __Symbol parent;
>   /* MaybeLater:
>   __SymbolType type;
>   __Symbol[] members;
>   ....
>  */
> }

Infinite recursion if a struct, I assume you mean class :P

On Sunday, 9 October 2016 at 04:12:48 UTC, Nicholas Wilson wrote:
> On Sunday, 9 October 2016 at 03:05:22 UTC, Stefan Koch wrote:
>> So far it can be visualized as
>> struct __Symbol
>> {
>>   string name;
>>   __Symbol parent;
>>   /* MaybeLater:
>>   __SymbolType type;
>>   __Symbol[] members;
>>   ....
>>  */
>> }
>
> Infinite recursion if a struct, I assume you mean class :P

It's a special compiler Symbol :) therefore it would know
But for the sake of normal rules see it as
struct __Symbol
{
  string name;
  __Symbol* parent;
}

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

On Sunday, 9 October 2016 at 13:40:14 UTC, Jacob Carlborg wrote:
>
> How about we just implement AST macros and be done with it :)

Walter would rather die. Then see ast-macros in D.

I must say they would probably be worse then templates, in regards of compile-time bloating.

On 2016-10-09 15:52, Stefan Koch wrote:

> Walter would rather die. Then see ast-macros in D.

Yeah, unfortunately. Instead a lot of features are proposed and some implement that all could be implement using macros. At the same time complaining that macros are complex. That's making the language complex is implementing a lot of small features that could have been implemented with a generic solution instead.

> I must say they would probably be worse then templates, in regards of
> compile-time bloating.

It's difficult to say without implementing and testing it out.

-- 
/Jacob Carlborg