[cfe-dev] Modules

[Thomas Young]

Hi,

I'm really looking forward to seeing modules support, this is something 
that I've been thinking about for a while now, and I think it really 
makes a lot of sense.

(When you see some big projects getting significant speedups from 
'unity' header compilation setups, and programmers then being unable to 
use stuff like static functions and anonymous namespaces that really 
seems like a big step backward!)

Just to add my 2 centimes, though:

   * I think that 'import' is misleading. (Since functionality is 
actually more similar to existing include mechanism, no namespace added, 
everything imported including macros, and so on. Main difference being 
really that current compilation state is not passed to the include.) 
Sticking with 'include', and no code changes, seems fine to me!

  * Watch out for proposed syntax changes distracting from the real 
story here. (See, for example the discussion 
athttp://forum.dlang.org/thread/k87qtm$2eu1$1@digitalmars.com 
<http://llvm.org/devmtg/2012-11/Gregor-Modules.pdf>.)

  * I see the real story here as being essentially in two parts:
   - Compiler and linker optimisation: i.e. for code set up a certain 
way it is possible to get very significant build speedups
   - Code quality improvements: I think that it is actually good coding 
style to setup headers in this way, and it will be cool to have some way 
to enforce this

I actually then want to use this kind of mechanism for pretty much 
_every_ header in our source tree.

In terms of setup, in the ideal case, all I would need to do would be to 
stick something like '#pragma is_independent_header' or '#pragma 
is_modular_header' at the top of each header.
The idea being that I basically want to declare, when I write the 
header, that this header is designed not to depend on any previous 
compilation state, and that any changes to the way the header compiles 
based on previous compilation state are undesirable.

Best regards,

Thomas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130122/22816b83/attachment.html>