Asking for advice - assert for ImportC

[Adam D Ruppe]

On Friday, 29 April 2022 at 15:10:28 UTC, Dennis wrote:
> Why not?

Long list:

* it is liable to outright break code, keeping a CTFE initializer 
while stripping the body. See:

ushort listeningPort = defaultListeningPort();
cgi.di(1165): Error: `defaultListeningPort` cannot be interpreted 
at compile time, because it has no available source code

Ideally, it would actually just evaluate it and spit out the 
answer instead of keeping the function there to be rerun each 
build.

* it keeps unnecessary imports

this would need to find unneeded imports and strip them, so new 
feature, but useful one

* it keeps bodies of constructors unnecessarily

this feels like it might just be a bug, since it removes other 
function bodies, but it might also have to do with a workaround 
for the uninitialized control flow logic

* it keeps private data and members

this means more imports must be kept which is a major compile 
time cost and limits encapsulation. keeping sizes and vtables 
syncing can be tricky, but replacing private data with private 
ubyte[N] blocks might work in some cases. postblits and such 
might complicate the issue. TLS might also complicate.

* it doesn't expand mixins

if something is mixed in locally with local arguments, might as 
well expand it here and prevent work. Another case of recognizing 
when CTFE can actually be cached or not; it depends on its 
parameters.

* you can't tell it to strip static ifs and versions

sometimes those checks are themselves a bit costly and again, 
some CTFE stripping opportunities.

* it doesn't collapse unnecessary templates to reuse impls

this is easier said than done so might need to be an external 
step though, but you can avoid creating new instances if it is 
already in the object file




I think that's my big items. My view of the .di generation is it 
can be a direct companion to a .obj file - it describes what is 
needed to use the object file and caches other source things. So 
together they'd minimize work done.

This isn't always what you want from it though, maybe you want 
reuse the same .di file from different builds but really if it is 
bundled with a .obj anyway - which is the case in a cached build 
and in a closed source distribution - I think there's a lot of 
potential in speeding things up.