Hi,

I've previously talked about the inherit compile-time impact of templates.
After talking  the problem through with a few people among them experienced D programmers, I am beginning to see that not everyone is aware what a template instantiation has to do.

let's take a simple identity template
template I(alias T)
{
    alias I = T;
}

now let's make an instance
I!(int) i1;

How does the compiler know what a template resolved to?
First it has to look up the _name_ 'I' from it's current scope, upwards.
// (depending on the depth (nestedness) of the scope that can actually take a lot of time.)
After it has found the template of the name 'I' it will now clone the body.
creating something like
{ alias I = _formal_param_1; }
after doing this it will now substitute the formal parameter (also known as just parameter) with the actual parameter (also known as argument).
resulting in this body :
{ alias I = int }
// (depending on the number of template parameters this too can be costly.)
then we substitute the newly created body with the instance which looks like this:
{ alias I = int } i1;
Of course this cannot compile since we don't pull a symbol out of the body.
I've for clarity omitted the handling of what is got publicized as the "eponymous template trick".
Before substituting we will actually try to look for a member in the template body which matches the name of the template and reference it.
Therefore

I!(int) i1;

actually results in:

{ alias I = int }.I i1;

and that's all there is to a simple templates instance.

let's repeat this for the type long

I!(long) l1;
copy the body
{ alias I = T; }
substitute the parameter
{ alias I = long; }
look for the eponymous member.
{ alias I = long; }.I
put it in place.
{ alias I = long; }.I l1;

Simple right?

And the fundamentals are really that simple.

However:
We have not covered how names are resolved in scopes;
Nor the intricacies of how to pick the right overload for a template.
And which implicit conversion happen for that;
Neither have we talked about deferred resolution of templates or
which steps semantic analysis has to take.

I will describe those in future posts as soon as I actually understand how the overload are picked ;)

Cheers,

Stefan

On Friday, 29 May 2020 at 11:13:17 UTC, Stefan Koch wrote:
> Hi,
>
> I've previously talked about the inherit compile-time impact of templates.
> After talking  the problem through with a few people among them experienced D programmers, I am beginning to see that not everyone is aware what a template instantiation has to do.
>
> [...]

P.S. If found this little article interesting please leave feedback.
P.P.S. Do remind me to talk about mangling as this is a rather interesting process.
(It too is very simple in principle)

On Friday, 29 May 2020 at 11:13:17 UTC, Stefan Koch wrote:

>
> I will describe those in future posts as soon as I actually understand how the overload are picked ;)
>


Blog post, perhaps? :-)

On Friday, 29 May 2020 at 11:26:49 UTC, Mike Parker wrote:
> On Friday, 29 May 2020 at 11:13:17 UTC, Stefan Koch wrote:
>
>>
>> I will describe those in future posts as soon as I actually understand how the overload are picked ;)
>>
>
>
> Blog post, perhaps? :-)

depends, did you find the article I wrote understandable and interesting?

I'd like to have a test-run here in the forums before putting it on the official blog.

On Friday, 29 May 2020 at 11:33:50 UTC, Stefan Koch wrote:

>
> depends, did you find the article I wrote understandable and interesting?

Yes, it's an interesting topic. It would need to be fleshed out into article form for the blog though. I'd be happy to work with you on that.

>
> I'd like to have a test-run here in the forums before putting it on the official blog.

Sure. When you've output all you want to say on the topic we can see about gathering shaping it up.

On Friday, 29 May 2020 at 11:26:49 UTC, Mike Parker wrote:
> On Friday, 29 May 2020 at 11:13:17 UTC, Stefan Koch wrote:
>
>>
>> I will describe those in future posts as soon as I actually understand how the overload are picked ;)
>>
>
>
> Blog post, perhaps? :-)

I think that this should go in the documentation or in some developers` manual. It is much easier to read it somewhere than to reverse engineer it from the code.

On Friday, 29 May 2020 at 11:33:50 UTC, Stefan Koch wrote:
> [snip]
>> Blog post, perhaps? :-)
>
> depends, did you find the article I wrote understandable and interesting?
>
> I'd like to have a test-run here in the forums before putting it on the official blog.

I think it was both understandable and interesting.

It might be worthwhile to wait to publish on the blog until you get the complete series so that you can be sure everything is consistent, then publish once a month or something like that.

On Friday, 29 May 2020 at 11:17:51 UTC, Stefan Koch wrote:
> P.S. If found this little article interesting please leave feedback.

Interesting and understandable.  It might also be nice to mention which functions/methods are responsible for the various pieces.  Agree it would be good for the blog at some point

On Friday, 29 May 2020 at 15:17:55 UTC, Ben Jones wrote:
> On Friday, 29 May 2020 at 11:17:51 UTC, Stefan Koch wrote:
>> P.S. If found this little article interesting please leave feedback.
>
> Interesting and understandable.  It might also be nice to mention which functions/methods are responsible for the various pieces.  Agree it would be good for the blog at some point

Those details would fill a few pages I am afraid.

I'd like to talk about the what has to happen rather than how it happens.
So that way it's a bit like reading the summery of a horror movie rather than watching the whole thing.

On Friday, 29 May 2020 at 16:04:06 UTC, Stefan Koch wrote:
> On Friday, 29 May 2020 at 15:17:55 UTC, Ben Jones wrote:
>> On Friday, 29 May 2020 at 11:17:51 UTC, Stefan Koch wrote:
>>> P.S. If found this little article interesting please leave feedback.
>>
>> Interesting and understandable.  It might also be nice to mention which functions/methods are responsible for the various pieces.  Agree it would be good for the blog at some point
>
> Those details would fill a few pages I am afraid.
>
> I'd like to talk about the what has to happen rather than how it happens.
> So that way it's a bit like reading the summery of a horror movie rather than watching the whole thing.

I would love to see a blog on this.

I would also love to see a follow on blog, if you have time, on the performance gains you're realizing in the area.  Your recent posts in other threads are very exciting.