Library standardization

[Yigal Chripun]

Sean Kelly wrote:
> == Quote from e-t172 (e-t172 at akegroup.org)'s article
>> Koroskin Denis a écrit :
>> - Ability to distribute closed-source libraries. I'm against
>> closed-source libraries, but I know that a lot of people need them.
>> Of course, header files also means additional maintenance issues. But it
>> shouldn't be too hard to write a program which automatically extract the
>> declarations and compile-time code out of a .d file, and use it to
>> generate a header file. This way, each time a .d file is modified, the
>> Makefile (or any other build system) would automatically trigger the
>> regeneration of the associated header file.
>> P.S.: I'm not talking about .di files here. Last time I tried to
>> generate .di files, implementation was still included in them.
> 
> The bodies of functions that can be inlined are included by default
> in .di files.  Recently, I suggested that this feature be sensitive to
> the -inline flag when creating the .di file.  It would be easy to
> implement and it seems logical to boot.  Feel free to submit it as
> an enhancement request, or any other ideas you have on this issue.
> 
> 
> Sean

Question/Suggestion:
where dmd currently puts the inlined function bodies inside the .di
file? It should be in a section of the file clearly separated from the
interface. what I mean is that the .di file should look something like this:
---
indented interface definition with comments/documentation
separator [like a comment saying: below is compiler stuff, don't touch]
inlined function bodies/other implementation code needed by the compiler
---

another thing, maybe D needs a separate file type for compile-time code.
for example, a .dc file [for D compile-time].
this file would contain only compile-time code like templates/ctfe
functions/macros/mixin definitions etc...
and regular .d files would only be allowed to contain code for run-time
and code that uses the compile time generated symbols. this separates
code meant for regular compilation from code written for compile-time
evaluation.
That would help simplify the language, i.e instead of using static if,
just use regular if. if it's in a .dc file than it'll be evaluated at
compile-time.
if you have a function that can be run both at compile-time and run
time, then you should be able to "import" it to your .d file without
rewriting it, [could be implemented via mixin or alias].
this would help both the user of the code to understand what code is
used at what stage and it'll help the compiler to provide different
handling for each case [for example, you need to compile only the .d
files into a library, since the .dc files should be provided to the user
as is so the user could provide them to his compiler. IDE writers would
benefit from this as well.

What do you think?

--Yigal