Library standardization

[e-t172]

Walter Bright a écrit :
> e-t172 wrote:
>> - Like you said, indentation is stripped. This make .di files quite 
>> ugly. Considering that .di files will often be directly read by the 
>> user of the API, this is a problem.
> 
> The .di files are meant for the compiler to read, not the user. They're 
> supposed to strip out all the extra whitespace and comments. Think of 
> them as "precompiled headers."

I agree with Bill Baxter: .di files should be more than that.

>> - If I understand your statement correctly, it means the D compiler 
>> decides on its own whether to inline a function or not.
> 
> That's right.
> 
> 
>> I don't think it's a good idea, because it will lead to very strange 
>> problems and unexpected behaviour when dealing with shared libraries. 
>> (actually this is not a .di issue, but a more general one).
> 
> It shouldn't lead to any observable behavior difference (other than 
> runtime speed and code size). Inlining should be the purvey of the 
> compiler much like which variables are to be enregistered.

I'm tired of repeating myself, so, copy/paste:

"The same kind of problem arises if you release a general update of your 
shared library without changing the API : the programs that uses the 
shared library will use the updated versions if and only if those are 
not inlined. This is normal, but because inlining a function is not a 
the programmer's decision in D, the program will use an ugly and 
unpredictable mix between updated and non-updated functions that will 
inevitably lead to grave problems (DLL hell reloaded?)."

In other words: when building a shared library, functions should *never* 
be inlined unless the programmer says so.