Compilation models (Was: Generic code: @autoconst, @autopure, @autonothrow )

[dsimcha]

== Quote from Robert Jacques (sandford at jhu.edu)'s article
> On Sun, 29 Aug 2010 00:42:49 -0400, Rainer Deyke <rainerd at eldwood.com>
> wrote:
> > On 8/28/2010 22:33, dsimcha wrote:
> >>> Is there any real reason why we can't apply these modifiers
> >>> automatically to all functions?  (And by "real" I don't mean "it would
> >>> be hard to do" or "it is incompatible with the archaic compilation
> >>> model
> >>> chosen by one D implementation".)
> >>
> >> Two reasons:
> >>
> >> 1.  Unless the function is a template, the compiler isn't guaranteed to
> >> have the
> >> source available.  What if it's a binary-only library?
> >
> > "It is incompatible with the archaic compilation model chosen by one D
> > implementation."
> >
> > This special treatment of templates has got to end.
> So... dynamic libraries (DLL's, etc.) are an archaic compilation model?
> Might you be able to suggest an newer alternative? (that doesn't involve a
> JIT, of course)

Sometimes I wonder if, once higher priority issues have been taken care of and D
is mainstream enough to support multiple dialects, we should create a D dialect
for standalone programs.  From a language specification point of view this would
be basically a superset of D, but would disallow separate compilation, i.e. all
non-extern(C) code for the entire project must be passed to the compiler in a
single invocation.  This would allow:

1.  Using templates to add virtual functions to classes.

2.  Compile-time introspection to get all descendants of a class.

3.  Better whole-program optimization, because no ABI for this dialect of D would
have to be specified, so the compiler could just do whatever is most efficient.