Future of D 2.x as stable/bug fix, and what's next for D 3.x

[Ola Fosheim Grøstad]

On Wednesday, 2 September 2020 at 14:09:12 UTC, bachmeier wrote:
> being garbage collected. You can use the GC to allocate data in 
> @nogc functions, but only if it's returned to a call that was 
> made from non- at nogc code.

So you are thinking about context-aware templates, that can query 
the properties of the call-chain? That is an interesting idea for 
static analysis indeed. Many things to consider though, when you 
have concurrency-mechanisms like coroutines.

There are many interesting things can be done to improve memory 
management for most languages, but one has to figure out what 
kind of constraints one are willing to impose on the language! If 
anything should be possible (on the low level) then that can 
inhibit some nice optimizations. For a GC-language you want to 
impose constraints on the language that some might considered 
inappropriate for writing and operating system kernel (most 
people don't write those, so it is not unreasonable to define 
writing kernels as out-of-scope for a language).

E.g. What happens if someone loads the whole file to GC-memory 
and then retains a pointer to a tiny slice of it. Can the runtime 
know that only that specific slice is "live"? If it can, then it 
can release the unused parts surrounding the slice (the big bulk 
of allocated memory). Can the runtime prove that there is only 
one reference to the slice? Then it can move it (compaction).

But the language semantics has to be hashed out very clearly and 
formally to do neat things like that safely (or to do them 
efficiently).

You basically need a very clear specification of what low level 
actions are defined as creating "undefined behaviour". You 
probably also need to introduce some constraints that some users 
will object to.