Could D be used by Jonathan Blow rather jai language?

Ola Fosheim Grøstad ola.fosheim.grostad at
Sat Nov 21 11:14:24 UTC 2020

On Saturday, 21 November 2020 at 05:51:53 UTC, Bruce Carneal 
> I don't have a comprehensive understanding of where D is at and 
> where it is headed wrt memory safety models.  The @live stuff 
> looks a little "iffy".  Hopefully Walter's upcoming talk will 
> help.

Yes, it will be interesting to see where D is headed.

Right now I think maybe automatic reference counting for dynamic 
arrays and class objects would go a long way, but...

The more I think about it, the more it makes sense to add Actor 
as a compiler construct and let that represent one thread (heavy 
or light). Then that Actor can have its own collection strategy 
and provide its own allocator in TLS. So for instance if most 
objects in that Actor is 100 bytes then it can have a separate 
heap for those. This can be profiled. Or if the Actor is short 
lived with low memory usage, just use a bump-allocator.

> As you note, some language advances may not be practical for D 
> but others could be built atop extant automated/correct 
> checking and some could be independent, never-existed-before, 
> capabilities where backward compatibility is not a concern: 
> type functions, monadic type variables, new memory guarantees, 
> arbitrarily prolonged "compile time", ...

I do at least hope that there will be clean guarantees for shared 
and nonshared memory, so that you can keep them on separate heaps 
and avoid atomics in allocators etc.

There is a need to list the language constraints that are needed 
to get semantic/runtime improvements. Some kind of matrix, 

More information about the Digitalmars-d mailing list