Prototype DIP11

[Jonathan M Davis]

On Monday, August 15, 2011 08:48:54 Jacob Carlborg wrote:
> On 2011-08-15 01:39, Jonathan M Davis wrote
> 
> > That's just not going to work. If you use .di files, you lose CTFE and
> > inlining for anything which isn't in the .di files. As such, there's a
> > definite advantage for a library to _not_ use .di files. There have
> > been some suggestions about how to fix that, but it's pretty much been
> > decided to put off fixing how .di files to D3.
> 
> How about putting the complete source code in the .di files and then the
> compiler will still be able to do CTFE and inline? But that might be no
> difference compared with a .d file.

There's definite flexibility with regards to what you choose to put in a .di file 
or not, though you do have to worry about CTFE and inlinability. From recent 
discussions on the issue, it was pretty much decided to table figuring out how 
to improve the situation with .di files until D3. They work right now, but you 
lose CTFEability and inlinability for anything which isn't in them, so it's up 
to the programmer to decide what they do and don't want to put in the .di file.

The point, however, is that you can't assume that a library will use .di files. 
It can choose to only use .d files. So, if you want to determine whether you 
need to compile .d files or not, you're going to have to use a method other 
than going by whether the source files provided are .di or .d. A package which 
provides only source and no compiled library would use .d files and need them 
to be compiled, whereas a library could use any combination of .di and .d files 
- including no .di files at all - and not need any of them to be compiled 
beyond what happens when importing them.

- Jonathan M Davis