Thread overview
Making template instantiations more lazy
Oct 18, 2017
Per Nordlöw
Oct 18, 2017
Jonathan M Davis
Oct 18, 2017
Nordlöw
Oct 18, 2017
Biotronic
Oct 18, 2017
Per Nordlöw
Oct 18, 2017
Per Nordlöw
Oct 18, 2017
Biotronic
Oct 18, 2017
Nordlöw
Oct 18, 2017
Jonathan M Davis
October 18, 2017
Are there any nearby plans to make more template instantiations (especially aggregate members) lazy in DMD?

Are there any specific obstacles against doing that or has it just not been prioritized?
October 18, 2017
On Wednesday, October 18, 2017 09:13:47 Per Nordlöw via Digitalmars-d-learn wrote:
> Are there any nearby plans to make more template instantiations (especially aggregate members) lazy in DMD?
>
> Are there any specific obstacles against doing that or has it just not been prioritized?

Templates are never instantiated unless they're actually... well, instantiated. So, they're already lazy in that sense. The compiler isn't pre-emptive with them at all. What exactly about them do you want to be lazy that isn't?

- Jonathan M Davis


October 18, 2017
On Wednesday, 18 October 2017 at 09:32:39 UTC, Jonathan M Davis wrote:
> On Wednesday, October 18, 2017 09:13:47 Per Nordlöw via Digitalmars-d-learn wrote:
>> Are there any nearby plans to make more template instantiations (especially aggregate members) lazy in DMD?
>>
>> Are there any specific obstacles against doing that or has it just not been prioritized?
>
> Templates are never instantiated unless they're actually... well, instantiated. So, they're already lazy in that sense. The compiler isn't pre-emptive with them at all. What exactly about them do you want to be lazy that isn't?
>
> - Jonathan M Davis

Member functions of templated containers is my main focus.
October 18, 2017
On Wednesday, 18 October 2017 at 09:56:33 UTC, Nordlöw wrote:
> On Wednesday, 18 October 2017 at 09:32:39 UTC, Jonathan M Davis wrote:
>> On Wednesday, October 18, 2017 09:13:47 Per Nordlöw via Digitalmars-d-learn wrote:
>>> Are there any nearby plans to make more template instantiations (especially aggregate members) lazy in DMD?
>>>
>>> Are there any specific obstacles against doing that or has it just not been prioritized?
>>
>> Templates are never instantiated unless they're actually... well, instantiated. So, they're already lazy in that sense. The compiler isn't pre-emptive with them at all. What exactly about them do you want to be lazy that isn't?
>>
>> - Jonathan M Davis
>
> Member functions of templated containers is my main focus.

Make them templates, that should solve the problem:

struct S(T) {
    void foo()() {
        compileerror;
    }
}
October 18, 2017
On Wednesday, 18 October 2017 at 10:17:38 UTC, Biotronic wrote:
>
> Make them templates, that should solve the problem:
>
> struct S(T) {
>     void foo()() {
>         compileerror;
>     }
> }

Yeah I've thought of that.

I still would like to have it built-in to the compiler.
October 18, 2017
On Wednesday, 18 October 2017 at 10:36:41 UTC, Per Nordlöw wrote:
> Yeah I've thought of that.
>
> I still would like to have it built-in to the compiler.

Would such a change cause any serious breakage?
October 18, 2017
On Wednesday, 18 October 2017 at 10:55:49 UTC, Per Nordlöw wrote:
> On Wednesday, 18 October 2017 at 10:36:41 UTC, Per Nordlöw wrote:
>> Yeah I've thought of that.
>>
>> I still would like to have it built-in to the compiler.
>
> Would such a change cause any serious breakage?

Seems unlikely - when did you last use a function without using it? :p

I'm not actually sure why D behaves this way - C++ doesn't. I guess there is some value as tests - instantiating the type tests that all its methods compile. Not actually sure that's more of a positive than a negative, but it's certainly never bothered me.

--
  Biotronic
October 18, 2017
On Wednesday, 18 October 2017 at 11:18:31 UTC, Biotronic wrote:
> I'm not actually sure why D behaves this way - C++ doesn't. I guess there is some value as tests - instantiating the type tests that all its methods compile. Not actually sure that's more of a positive than a negative, but it's certainly never bothered me.
>
> --
>   Biotronic

I wonder if the fix simple (to Walter at least).

It would save container-heavy projects noticeable build time.

Adding () to the member functions did it for mine at least.
October 18, 2017
On Wednesday, October 18, 2017 10:36:41 Per Nordlöw via Digitalmars-d-learn wrote:
> On Wednesday, 18 October 2017 at 10:17:38 UTC, Biotronic wrote:
> > Make them templates, that should solve the problem:
> >
> > struct S(T) {
> >
> >     void foo()() {
> >
> >         compileerror;
> >
> >     }
> >
> > }
>
> Yeah I've thought of that.
>
> I still would like to have it built-in to the compiler.

If you actually needed all of the member functions to fully exist, that would make life a lot harder (e.g. if you're doing something with language bindings and need to guarantee that a particular template instantiation fully exists). And if you suddenly couldn't guarantee that everything within a template was instantiated when the template was instantiated, then you basically have code that looks like it exists but doesn't actually, and that would make it rather difficult to know what code actually exists, whereas right now, if you instantiate a template, you know exactly what code then exists because of that instantiation.

At least with the ability to separately templatize member functions, you can control what's going on.

- Jonathan M Davis