On Friday, 29 April 2022 at 02:29:25 UTC, rikki cattermole wrote:
>
> On 29/04/2022 2:24 PM, Salih Dincer wrote:
>> Although I don't understand it technically (what are DI files?),
>
> .di files are like regular .d files except by convention non-templated functions have their bodies removed.

How I can prevent a function body from being removed in an interface file (because that function should be evaluated at compile time)?

On Friday, 29 April 2022 at 02:29:25 UTC, rikki cattermole wrote:
>
> On 29/04/2022 2:24 PM, Salih Dincer wrote:
>> Although I don't understand it technically (what are DI files?),
>
> .di files are like regular .d files except by convention non-templated functions have their bodies removed.

When are they needed?

On Friday, 29 April 2022 at 13:15:10 UTC, Guillaume Piolat wrote:

>>
>> .di files are like regular .d files except by convention non-templated functions have their bodies removed.
>
> When are they needed?

I think the primary use case would be if you want to distribute a closed-source library.

On Friday, 29 April 2022 at 13:15:10 UTC, Guillaume Piolat wrote:
> When are they needed?

They are never needed, per se, but they have some potential in improving compile time by caching some results and hiding implementations. Especially combined with local imports, hiding the body can hide the entire import web, which can hide whole ctfe calculations.

I also think we can set it to avoid template generations by doing them extern if it is already in the lib which can further help compile times if all goes well.

The hard part is keeping it in sync. The compiler won't help you at all, aside from its -H generation, which isn't great. And if you forget to regenerate, you have possible ABI mismatch; the compiler won't check against an intended thing.

(This is something I'd love to see a dub 2.0 tackle.)

On 4/29/22 02:59, Loara wrote:

> How I can prevent a function body from being removed in an interface
> file

Other than templates, the compiler needs the bodies of 'auto' functions to determine what type they return:

auto foo() {
  // ...
}

> (because that function should be evaluated at compile time)?

You simply use the .d file that includes the definitions during compilation.

I always saw .di files as the .h equivalents of C, which are not needed in D but for distributing a library. (I don't think I will ever need them.)

Ali

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.

On 30/04/2022 1:15 AM, Guillaume Piolat wrote:
> On Friday, 29 April 2022 at 02:29:25 UTC, rikki cattermole wrote:
>>
>> On 29/04/2022 2:24 PM, Salih Dincer wrote:
>>> Although I don't understand it technically (what are DI files?),
>>
>> .di files are like regular .d files except by convention non-templated functions have their bodies removed.
> 
> When are they needed?

I will be using them for my shared libraries.

There are some expensive bits that I really don't want to be reparsed (nor does it need to be).

Most people probably won't need to use them as others have said.

On 4/28/2022 1:02 AM, duser wrote:
> maybe `_Assert`? similar to `_Static_assert`
> 
> it almost looks like something you could expect to see in a future C standard
> 
> adding a prefix to the double-underscore name would be the safe but boring option, something like `__d_assert` or `__importc_assert`

I like __importc_assert, except it's a bit long.

I've also thought of __check() which is congruent with the compiler switch -checkxxxxx