On Tue, 18 Aug 2009 10:57:50 -0700, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Tue, 18 Aug 2009 13:48:23 -0400, Robert Jacques <sandf...@jhu.edu>
wrote:
On Tue, 18 Aug 2009 10:38:50 -0700, Steven Schveighoffer
<schvei...@yahoo.com> wrote:
On Tue, 18 Aug 2009 13:34:36 -0400, bearophile
<bearophileh...@lycos.com> wrote:
Steven Schveighoffer:
Another way is to perform escape analysis, but Walter has expressed
that
he doesn't want to do that. It would require an intermediate
interface
language for imports where annotations could be added by the
compiler.
Why is that bad?
I don't think it's bad, but definitely a lot of work. I would be all
for it.
-Steve
Actually, it's really bad. Escape analysis requires whole program
analysis. It would be impossible to do incremental compilation or to
ship/sell D libraries in binary format. I'd recomend checking out
http://en.wikipedia.org/wiki/Escape_analysis for an overview of the
issues involved. You can avoid doing whole program analysis by
introducing ownership types and being a bit conservative in what you
allow. There's a (bit confusing) wiki page proposal an how to implement
it at http://www.prowiki.org/wiki4d/wiki.cgi?OwnershipTypesInD.
Admitting I didn't read any of that, I think incremental analysis is
possible as long as import files are generated by the compiler
post-analysis. i.e. the compiler is able to alter the function
signature indicating escape analysis information.
With something like that, you could still ship in binary format, along
with generated import files that describe the function signatures (if
one requires building against your product). In fact, the import files
could be a part of the binary files, similar to how java works.
-Steve
*sigh* That doesn't work. From the wikipedia article:
In traditional static compilation, method overriding can make escape
analysis impossible, as any called method might be overridden by a
version that allows a pointer to escape.
For example: Let's take a 3rd party pre-compiled library with class A and
function f(A a), neither of which have any escapes. Now create a subclass
of A, B, which does contain escapes. Does f(B) escape or not?
Now, introducing some ownership types, (scope, stack, heap, shared,
mobile), gives the compiler / methods the guarantees they need to get over
this problem.
