On Mon, Jan 21, 2013 at 11:36:58PM +0100, Paulo Pinto wrote: > Am 21.01.2013 22:25, schrieb H. S. Teoh: [...] > >Hmm. So you're essentially saying that the compiler will do > >compile-time analysis of variable usage, and based on that choose the > >simplest memory management model for it? > > > >That's not a bad idea. You can have a series of increasingly complex > >management techniques, and the compiler could choose the least > >complex one that it can statically prove is safe. So if something can > >be proven not to escape the current scope, it can even be > >stack-allocated (or if it's big, put it on the manual heap and delete > >it on scope exit). If it is returned with no other references to it, > >then it can be a single-reference pointer (i.e. your owner type). If > >it has cyclic references, use a reference-counted pointer. If all > >else fails, fall back to the GC. > > > >The problem is that quite often, the compiler will not be able to > >prove much about the data structure, esp. when you have non-trivial > >manipulation of pointers -- it requires solving the halting problem > >to achieve that level of analysis on arbitrary code -- so it will > >probably fall back to the GC quite often, depending on what the code > >does. [...] > I see how this could work in a JIT environment, but not in a static > compiler with modules compiled in separate ways. [...]
It can be made to work with separately-compiled modules if there's language support (say in the form of exported pointer attributes). But probably not feasible in the current version of D. T -- Designer clothes: how to cover less by paying more.