On Friday, 15 October 2021 at 10:26:51 UTC, Imperatorn wrote:

I think that's his problem. D doesn't have a specific philosophy about memory management.

On Friday, 15 October 2021 at 10:58:14 UTC, bauss wrote:

This is fine. But here is the deal: that means D cannot have a philosophy on safety. Or have closure allocated on the GC by default. Or a gazilion other things.

It's the same problem, just in another dimension: a decision is made, ut then consequences are not accepted.

On Friday, 15 October 2021 at 11:57:28 UTC, deadalnix wrote:

using allocators aware APIs solves all of this, look at zig!

it is a problem already solved, use allocators and don't assume one is using GC or other means

--

on the nullable thingy, i agree 100%, we now got 2 way for null

• null keyword

• isNull method

nice! in the std! it's standard now!..

On Friday, 15 October 2021 at 13:21:25 UTC, russhy wrote:

This is just bad naming--isNull should be called empty. It has nothing to do with null.

On Friday, 15 October 2021 at 13:21:25 UTC, russhy wrote:

Many D construct assume a GC. Which kinda is the point. Either you don't assume a GC and go the zig road, or you assume a GC. But D is trying to have its cake and eat it too, and the result is schizophrenic in nature.

At some point you need to chose a path. And if you don't want to chose a path at level N to leave that to the user, then you need to pick a path at level N-1 or bellow.

On Friday, 15 October 2021 at 13:45:11 UTC, deadalnix wrote:

This problem could still be solved by making the GC just another allocator (and make it the default global allocator). D's current GC only runs when an allocation is made anyway, so doing this shouldn't break the behavior of existing code (except leaking memory if the constructs that assume GC is used, of course).

Maybe from this point on those constructs can be made to use reference counting instead and make sure they're allocator-independent.

On Friday, 15 October 2021 at 14:24:16 UTC, SomeGuy wrote:

Bring back new and make it configurable 😎

On Friday, 15 October 2021 at 14:24:16 UTC, SomeGuy wrote:

The biggest obstacle is that D has no fat pointers. It has only pointers which is enough when you have tracing GC but not enough if your pointers requires extra metadata.

This is one of the biggest mistakes in D which limits the possibility to change GC type. Other languages like Nim have a reference types which is a fat pointer type. Nim has gone through more GC types in a shorter time than D.

Fat pointers come at a cost though which might be extra dereferences as your data is an inner pointer member. In practice this is already possible in D as a library solution. Problem is that you cannot easily change Druntime/Phobos to also use your custom GC.

On Friday, 15 October 2021 at 13:30:46 UTC, Paul Backus wrote:

Now let's break code again and rename it!

On Friday, 15 October 2021 at 14:24:16 UTC, SomeGuy wrote:

Yes i agree with you, that would make everyone happy and would be transparent without breaking any existing code