Request for Comment assert(__ctfe)

[Johannes Pfau]

Am Sun, 05 Apr 2020 18:40:31 +0000 schrieb Petar Kirov [ZombineDev]:

> On Sunday, 5 April 2020 at 18:30:25 UTC, Stefan Koch wrote:
>> On Sunday, 5 April 2020 at 18:25:10 UTC, Petar Kirov [ZombineDev]
>> wrote:
>>> On Sunday, 5 April 2020 at 12:11:23 UTC, Stefan Koch wrote:
>>>> [...]
>>>
>>> Another, more radical and interesting option is to not perform codegen
>>> unless it's actually necessary. Instead of blacklisting `@ctfe` or
>>> `assert(__ctfe)` functions, have a whitelist of what functions are
>>> allowed to codegen-ed.
>>>
>>> [...]
>>
>> Seems like you are reading my mind.
>> Indeed this is one of next steps ...
>> assert(__ctfe) did not break a single package, in out CI! Therefore I
>> do now have enough confidence in crawling the dynamic dependencies
>> outwards from the entry point and exported functions.
>>
>> That however is for the future and will require me to do some
>> theoretical work, in order to proof to myself that it actually is
>> feasible and won't end up in a nightmare of subtly broken builds.
> 
> Great! Perhaps we should write a DIP to specify the semantics of such a
> lazy compilation model? An even more extreme option would be to not
> perform semantic analysis on non-`export`-ed functions.
> This should bring some really high gains, though it would be the
> trickiest to adopt option for users.

How would such a lazy compilation model work without explicit 'export' 
anotations? If I wanted to build a proprietary library libfoo.so and 
provide only .di files with stripped function bodies, all functions have 
to be compiled into the .so file. But how does the compiler know the 
result is going to be a shared library in a separate compilation model, 
where the compiler produces only an object file?

I guess such a lazy compilation model might be quite interesting, but as 
it is a quite radical idea, it needs lots of thinking, proper 
specification and testing first. (Testing as you'll probably have to emit 
everything as weak symbols then, and you probably want to test how 
linkers deal with that if you make excessive use of it)


-- 
Johannes