On Friday 04 May 2012 11:17 PM, H. S. Teoh wrote:
On Fri, May 04, 2012 at 03:13:21PM -0400, Steven Schveighoffer wrote:
[...]
I think he meant that object (and library) binary files would be
augmented by API segments that provide what di files provide now --
an interface-only version of the code. It doesn't have to be text,
it can be binary (maybe even partially compiled).
The really nice thing you get from this is, the compiler now would
use this object file instead of .d files for importing. So not only
do you eliminate errors from having two possibly separately
maintained files, but the compiler can build *extra* details into
the .dobj file. For example, it could put in metadata that would
allow for full escape analysis. Or tag that a function is implied
pure (without actually having to tag the function with the pure
attribute).
[...]
+1. It's about time we moved on from 30+ year old outdated linker
technology, to something more powerful. Full escape analysis, compiler
deduced function attributes like pureness, all the stuff that's
impractical to implement in the current system, can all be done in a
reasonable way if we stuck this information into the object files. The
linker doesn't have to care what's in those extra sections; the compiler
reads the info and does what it needs to do. The linker can omit the
extra info from the final executable. (Or make use of it, if we
implement a smarter linker. Like do cross-module string optimization, or
something.)
T
Purity inference won't happen either way. Purity is part of your API and
also meant to help you reason about your code. If the compiler just
infers purity in a function and you later change the implementation so
it's no longer pure, you break your users' code. Also, purity would no
longer help you reason about your code if it's not explicit.
--
- Alex
