Future of memory management in D

[Tejas]

On Tuesday, 16 November 2021 at 18:17:29 UTC, Rumbu wrote:
> At least from my point of view, it seems that recently D made a 
> shift from a general purpose language to a C successor, hence 
> the last efforts to improve betterC and C interop, neglecting 
> other areas of the language.
>
> By other areas I mean half baked language built-ins or oop 
> support which failed to evolve at least to keep the pace with 
> the  languages from where D took inspiration initially (e.g. 
> Java and its successors).
>
> In this new light, even I am not bothered by, I must admit that 
> the garbage collector became something that doesn't fit in.
>
> Now, without a gc, more than half of the language risks to 
> become unusable and that's why I ask myself how do you see the 
> future of the memory management in D?
>
> For library development it is not necessary a big deal since 
> the allocator pattern can be implemented for each operation 
> that needs to allocate.
>
> But, for the rest of the features which are part of the core 
> language (e.g. arrays, classes, exceptions) what memory model 
> do you consider that will fit in? Do you think that compiler 
> supported ARC can be accepted as a deterministic memory model 
> by everyone? Or memory ownership and flow analysis are better?
>
> Not assuming a standard memory model can be a mistake, the C 
> crowd will always complain that they cannot use feature X, 
> others will complain that they cannot use feature Y because it 
> is not finished or its semantics are stuck in 2000's.

D always aimed to be a C/C++ successor though. It had Java 
influences, but that's it, it always had the ambitions of being a 
systems programming language.

That it was flexible enough to even be good for scripting tasks 
was an accidental boon(and downfall:
- since GC means no system programming; and instead of removing 
GC/embracing GC, we're stuck in-between, and
- ARC seems to be a pipe dream for some reason;
- front-end refactoring is considered infeasible and
- code-breakage is only allowed as regression, ie, a bug that 
must be fixed).