On 16/09/2023 9:02 PM, Adam Wilson wrote:
> I know there are ref-counted languages so theoretically it should be workable, but the in a language as complex as D there may be dragons on the edges.

The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.

Then you borrow memory from them, and DIP1000 takes over.

This minimizes the surface area of the language that needs to understand reference counting and life time handling. So our one dimensional approach with DIP1000, will absolutely shine.

I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.

On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki) Andrew Cattermole
wrote:
>
> The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.

Does that mean you are against dip1000 or do you want both?

> I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.

Will it be automated reference counting with a special type of GC doing the job or a local RC container?

On 17/09/2023 12:25 AM, sighoya wrote:
> On Saturday, 16 September 2023 at 10:22:31 UTC, Richard (Rikki) Andrew Cattermole
> wrote:
>>
>> The approach that I think will work well for us is to support reference counting on structs & classes, and make them not adhere to DIP1000.
> 
> Does that mean you are against dip1000 or do you want both?

Basically DIP1000 handles the final leg of lifetime management, rather than managing the actual ownership of memory. It comes into play after you borrow from a container.

>> I will be doing the DIP for RC due to its cost of it and the fact that modern backends do understand it and can make it cheaper.
> 
> Will it be automated reference counting with a special type of GC doing the job or a local RC container?

Its basically what we do now with copy constructors + destructors, but inside dedicated methods.

Although I do want a write barrier on each struct/class, to allow for cyclic handling especially for classes.

On Saturday, 16 September 2023 at 12:34:24 UTC, Richard (Rikki) Andrew Cattermole wrote:
> Although I do want a write barrier on each struct/class, to allow for cyclic handling especially for classes.

How dare you bring the High Heresy of write barriers into D! I thought that it was well understand that even mentioning Write Barriers is a mortal sin against the Church of @nogc.

Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).

On 17/09/2023 11:46 AM, Adam Wilson wrote:
> Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).

The scope of each doesn't match up, and you'd still need the RC specific write barriers.

So when I say write barrier what I mean is:

```d
class MyRoot : void {
	void opRCWriteBarrier(size_t fieldOffset, void* pointer) {
		myCyclicDetector.set(cast(void*)this, fieldOffset, pointer);
	}

	void opRCSub() {
		if (atomicOp!"-="(this.refCount, 1) > 0)
			myCyclicDetector.collect(cast(void*)this);
	}
}

class Child : MyRoot {
	Array!int array;

	void func() {
		array = new Array!int();
		// this.opRCWriteBarrier(array.offsetof, cast(void*)array);
	}
}
```

Only needs to support classes + structs (I think), so its surface area is pretty small.

Oh and Walter has approved anyone to experiment with write barriers ages ago, although nobody has.

On Sunday, 17 September 2023 at 00:55:22 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 17/09/2023 11:46 AM, Adam Wilson wrote:
>> Kidding aside. If you do this, you might as well turn them on everywhere. After that it's a easy stroll to a non-blocking moving GC, which would end most complaints about the GC (nobody complains about the .NET GC anymore).
>
> The scope of each doesn't match up, and you'd still need the RC specific write barriers.
>
> So when I say write barrier what I mean is:
>
> ```d
> class MyRoot : void {
> 	void opRCWriteBarrier(size_t fieldOffset, void* pointer) {
> 		myCyclicDetector.set(cast(void*)this, fieldOffset, pointer);
> 	}
>
> 	void opRCSub() {
> 		if (atomicOp!"-="(this.refCount, 1) > 0)
> 			myCyclicDetector.collect(cast(void*)this);
> 	}
> }
>
> class Child : MyRoot {
> 	Array!int array;
>
> 	void func() {
> 		array = new Array!int();
> 		// this.opRCWriteBarrier(array.offsetof, cast(void*)array);
> 	}
> }
> ```
>
> Only needs to support classes + structs (I think), so its surface area is pretty small.
>
> Oh and Walter has approved anyone to experiment with write barriers ages ago, although nobody has.

I hope we'll see tagged union + tuple come first before that mess you are describing, because to me this sound like a giant waste of effort, time and opportunity

You'll never attract more people if you focus on OOP / GC, that kind of code is repulsive to be honest

Tagged Union alone will help build libraries that doesn't require that OOP crap and help reduce the need of a GC significantly, more structs, less class, more values less heap allocated garbage for a collector to stop the world

D has ton of features that help avoid GC completely, let's focus on more of that

Atila, didn't you say "allocator good", so where are they? leadership is also frozen?