new DIP47: Outlining member functions of aggregates

Dicebot public at dicebot.lv
Tue Sep 10 05:24:58 PDT 2013


Main issue of .di files that make them useless for anything but 
providing declarations for blobs is that there is absolutely zero 
compiler control of .d and .di relation. Fixing this either 
implies providing good control of how .di is generated via 
compiler flags (and prohibiting manual modifications) or 
implementing good part of DIP47 restricted to .di/.d combo (all 
the signature verifications).

Also it does not seem defined in spec how lookup should happen if 
both .d and .di are present, and, for example, .di has only 
declaration. Will compiler check .d for possible inlining if it 
is present?

I think that .di should always contain only declarations and be 
_always_ auto-generated by compiler with strict 1-to-1 matching 
signatures. Then .d are also queried if implementation is 
needed/considered - but those are not mandatory (aside from 
templates). Blob bindings distributed may then simply have a 
stripped down version of .d file (similar to what is now 
generated by dmd -H).

Key point here is  that .di needs _always_ to be there, with hard 
guarantees that it is in sync with actual code. Add even one more 
extra step of getting those and it becomes considerably less 
convenient than C++-like overview.


More information about the Digitalmars-d mailing list