I've been using a lot of CTFE in my libraries and this has had the side effect of increasing my link time beyond 13 seconds. There's a pretty big chunk of those symbols being exported that are used only for evaluating mixins.

Would there be a way to specify something in the lines of `extern (none):` or `intern:`?

On Mon, 20 Apr 2015 09:22:17 -0400, Etienne wrote:

> I've been using a lot of CTFE in my libraries and this has had the side effect of increasing my link time beyond 13 seconds. There's a pretty big chunk of those symbols being exported that are used only for evaluating mixins.
> 
> Would there be a way to specify something in the lines of `extern
> (none):` or `intern:`?

i think you should make ER for this. it will be fine if there will be the way to tell compiler to skip code generation for some functions which used only in CTFE.

On Mon, 20 Apr 2015 13:34:47 +0000, ketmar wrote:

> On Mon, 20 Apr 2015 09:22:17 -0400, Etienne wrote:
> 
>> I've been using a lot of CTFE in my libraries and this has had the side effect of increasing my link time beyond 13 seconds. There's a pretty big chunk of those symbols being exported that are used only for evaluating mixins.
>> 
>> Would there be a way to specify something in the lines of `extern
>> (none):` or `intern:`?
> 
> i think you should make ER for this. it will be fine if there will be the way to tell compiler to skip code generation for some functions which used only in CTFE.

by the way, maybe it will be good to add `extern(CTFE)` too, so hdrgen can emit source code for such functions to .di file. i.e.

`extern(none)` -- don't generate code, don't emit to .di
`extern(CTFE)` -- don't generate code, emit to .di

Am 20.04.2015 um 15:22 schrieb Etienne:
> I've been using a lot of CTFE in my libraries and this has had the side
> effect of increasing my link time beyond 13 seconds. There's a pretty
> big chunk of those symbols being exported that are used only for
> evaluating mixins.
>
> Would there be a way to specify something in the lines of `extern
> (none):` or `intern:`?

Any reason why "private" couldn't be used for this? If a private function is only used for CTFE, there is no need to generate code at all.

On Monday, 20 April 2015 at 13:22:15 UTC, Etienne wrote:
> I've been using a lot of CTFE in my libraries and this has had the side effect of increasing my link time beyond 13 seconds. There's a pretty big chunk of those symbols being exported that are used only for evaluating mixins.
>
> Would there be a way to specify something in the lines of `extern (none):` or `intern:`?

what happens with totally empty functions ? can't they be removed on compilation ? static if(__ctfe){} could be used to make those empty for non-ctfe then..

On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:

> static if(__ctfe){}

small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. ;-)

On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:
> On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:
>
>> static if(__ctfe){}
>
> small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. ;-)

__ctfe is not readable at compile time ? thats unfortunate..

On Monday, 20 April 2015 at 20:04:04 UTC, Sönke Ludwig wrote:
> Am 20.04.2015 um 15:22 schrieb Etienne:
>> I've been using a lot of CTFE in my libraries and this has had the side
>> effect of increasing my link time beyond 13 seconds. There's a pretty
>> big chunk of those symbols being exported that are used only for
>> evaluating mixins.
>>
>> Would there be a way to specify something in the lines of `extern
>> (none):` or `intern:`?
>
> Any reason why "private" couldn't be used for this? If a private function is only used for CTFE, there is no need to generate code at all.

Need much more powerful flow analysis than DMD frontend is currently capable of. Specifically, it needs to ensure that this function is also not taken address of and not aliased via any of public templates (transitively), as well as not aliased to something available as public.

On Mon, Apr 20, 2015 at 09:00:34PM +0000, extrawurst via Digitalmars-d wrote:
> On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:
> >On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:
> >
> >>static if(__ctfe){}
> >
> >small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error. ;-)
> 
> __ctfe is not readable at compile time ? thats unfortunate..

"Compile time" is actually a broad term that is not precise enough to describe the distinction between template expansion / static if and CTFE.

Basically, static if and template expansion happens at an earlier stage of the compilation process -- conceptually speaking, somewhere between parsing and semantic analysis. Perhaps one could think of it as AST transformation prior to the AST being interpreted by the compiler. At this stage, no semantic values (e.g., the state of variables, etc.) are available, because the AST is not being interpreted yet.

CTFE, on the other hand, conceptually sits between semantic analysis and code generation, which is at a later stage than the AST transformation of templates / static if. Basically, at this point the AST is fixed and the compiler is ready to emit object code, but instead of doing so, runs it through an interpreter instead. So at this stage the compiler has enough information to keep track of the values of variables and stuff, and can simulate the effect of executing code at runtime. However, in order for this simulation to have well-defined semantics, AST transformations are no longer possible, so you cannot evaluate static ifs in the CTFE stage.

This is why the __ctfe magic variable cannot be read at compile-time, or, to be more precise, at AST transformation time. It can only be read at CTFE-time.

Of course, this is a greatly simplified picture of how things actually work in the compiler. The compiler isn't confined to a single AST tranformation stage followed by a single CTFE stage; the whole point of CTFE is that the result of the CTFE is fed back into the compiler to influence AST transformation in another part of the code. This can be done by running semantic analysis on the code to be CTFE-'d first, so that it's ready for interpretation when another part of the code that needs the CTFE value is still in the AST transformation stage. Everything is eventually resolvable, as long as there are no circular dependencies.

Nevertheless, the distinction between AST transformation and CTFE is an important one (at least conceptually).  The function being CTFE'd must be fully compiled before it can be CTFE'd (even if the rest of the code isn't fully compiled yet), so static if must already be evaluated by the time CTFE runs. Conversely, a static if / template expansion is by definition not yet fully compiled, so it cannot evaluate references to variables, even if said variables exist in CTFE (since CTFE hasn't started yet at that point).


T

-- 
I'm still trying to find a pun for "punishment"...

On Mon, 20 Apr 2015 21:00:34 +0000, extrawurst wrote:

> On Monday, 20 April 2015 at 20:36:06 UTC, ketmar wrote:
>> On Mon, 20 Apr 2015 20:31:36 +0000, extrawurst wrote:
>>
>>> static if(__ctfe){}
>>
>> small fix: simply `if (__ctfe)`, `static if (__ctfe)` is error.
>> ;-)
> 
> __ctfe is not readable at compile time ? thats unfortunate..

it will have no sense. DMD is able to eliminate dead code in this case, so `if (__ctfe)` will generate plain function. and there is no sense in do `static if` for functions, as functions is not instantiating, i.e. that will be processed only once, and you will be unable to use function both in CTFE and in run time.