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