On Friday, 20 November 2020 at 22:29:39 UTC, Ola Fosheim Grostad wrote:
> On Friday, 20 November 2020 at 20:22:14 UTC, aberba wrote:
>> they write D code like Java code. Every language has its own idiomatic way of doing things and its own tricks.
>
> Right, but it is important to keep in mind that those idioms are cultural constructs, so if the language is flexible like D, you need to be smart on a cultural level to establish "code interface norms". This is where having gc, nogc, betterC etc can become a serious problem.

My point is the GC-nogc computer is never an issue for me. Its just makes D useful for many other domains that I'm interested in.

So you'll have to look at the kind of software you write.

On Saturday, 21 November 2020 at 05:51:53 UTC, Bruce Carneal wrote:
> 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, perhaps.

On Saturday, 21 November 2020 at 11:06:45 UTC, aberba wrote:
> My point is the GC-nogc computer is never an issue for me. Its just makes D useful for many other domains that I'm interested in.
>
> So you'll have to look at the kind of software you write.

Well, if nogc is going to be an alternative to C++/Rust then something has to be done as interfacing implies a  of risk confusing gc memory with nongc memory. Most interesting code is building a graph of some sort.

Basically, it should be easy to write a library that is both nongc and gc at the same time.

It implies that owning pointers basically has to be templated, with a retention mechanism for nogc code.