So I came here to ask about things that prevent D to become better.

What language semantics prevent precise & fast GC implementations?

What makes it impossible to have ref counted classes?

What are some other technical / design problems you encountered? (other than poor implementation and lack of resources)

Enlighten! :)

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
> What language semantics prevent precise & fast GC implementations?

This prevents fast GC: Pointers.

This prevents precise GC: internal Pointers + FFI.

Go now has <10ms latency for small heaps, <20ms latency for up to 100GB heaps and <40ms latency for up to 250GB heaps.

But IIRC when calling a  C function in Go, the function called should not retain pointers or go down indirections?

https://talks.golang.org/2016/state-of-go.slide#37


So, basically, if you want fast memory release, forget using the GC in D.

> What makes it impossible to have ref counted classes?

Nothing.

> What are some other technical / design problems you encountered? (other than poor implementation and lack of resources)

Lack of focus on what most programmers expect from system level programming.

On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote:
>> What makes it impossible to have ref counted classes?
>
> Nothing.

Then why do we need DIP74 ? And why documentation says RefCounted doesn't work with classes?

On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote:
> On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote:
>>> What makes it impossible to have ref counted classes?
>>
>> Nothing.
>
> Then why do we need DIP74 ?

I think they aim for compiler optimizations, like ARC on Swift. But ARC requires all ref counting to be done behind the scene, so I think it is a bad idea for D to be honest.

> And why documentation says RefCounted doesn't work with classes?

I don't use Phobos much. I think RefCounted creates a wrapper for an embedded struct or something. Something like struct { int refcount; T payload; }

Nothing prevents you from creating your own reference counting mechanism.

On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote:
> On Saturday, 6 February 2016 at 11:09:28 UTC, NX wrote:
>> On Saturday, 6 February 2016 at 10:29:32 UTC, Ola Fosheim Grøstad wrote:
>>>> What makes it impossible to have ref counted classes?
>>>
>>> Nothing.
>>
>> Then why do we need DIP74 ?
>
> I think they aim for compiler optimizations, like ARC on Swift. But ARC requires all ref counting to be done behind the scene, so I think it is a bad idea for D to be honest.
>
>> And why documentation says RefCounted doesn't work with classes?
>
> I don't use Phobos much. I think RefCounted creates a wrapper for an embedded struct or something. Something like struct { int refcount; T payload; }
>
> Nothing prevents you from creating your own reference counting mechanism.

reference counting is incredibly slow, DIP74 attempts to partially amend that in D as it can't be done any other way besides compiler help.
IIRC, it essentially just allows RC inc/dec to be elided where possible

On Saturday, 6 February 2016 at 11:33:05 UTC, rsw0x wrote:
> On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote:
> reference counting is incredibly slow, DIP74 attempts to partially amend that in D as it can't be done any other way besides compiler help.
> IIRC, it essentially just allows RC inc/dec to be elided where possible

_Automatic_ reference counting can be slow. Manual reference counting can be very efficient (but takes programmer skill).

The better solution is to adopt borrow-semantics and only use reference counting for ownership. Just like you ought to use unique_ptr and shared_ptr in C++.

Of course, Swift does not aim for very high performance, but for convenient application/gui development. And frankly JavaScript is fast enough for that kind of programming.

On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
> What language semantics prevent precise

Lack of resources. Precise GC needs to know which fields are pointers. Somebody must generate that map. AFAIK there was an experiment on that.

> fast GC

Fast GC needs to be notified about pointer changes, C won't do that and for some reason people don't want to rely on C code not changing GC pointers.

On Saturday, 6 February 2016 at 15:14:06 UTC, Kagamin wrote:
> On Saturday, 6 February 2016 at 08:07:42 UTC, NX wrote:
>> What language semantics prevent precise
>
> Lack of resources. Precise GC needs to know which fields are pointers. Somebody must generate that map. AFAIK there was an experiment on that.

That information has already been present for a couple of releases
(http://dlang.org/spec/traits.html#getPointerBitmap), however currently the precise GC is slower than the conservative one, because of the overhead the the extra metadata has. For more info, you can read the comments on these two PRs:
https://github.com/D-Programming-Language/druntime/pull/1022
https://github.com/D-Programming-Language/druntime/pull/1057

On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote:
> Nothing prevents you from creating your own reference counting mechanism.

A struct wrapper doesn't give the things you need to reliably handle inheritance.

interface A {}
interface B {}
class C : A, B {}

void use(RefCounted!A) {}

RefCounted!C c;
use(c);



With alias this tricks, you can handle one level of inheritance, you could make it return a RefCounted!A or B, but not both. Multiple alias this could solve this... but that PR is in limbo again AFAIK.

Of course, you could just write some named function to return the right interface and tell the user to call it, but it won't be an implicit conversion like it is with interfaces normally.

(BTW, for the record, I have no problem with named functions, it just is different than the built-in thing.)

On Saturday, 6 February 2016 at 17:22:03 UTC, Adam D. Ruppe wrote:
> On Saturday, 6 February 2016 at 11:15:06 UTC, Ola Fosheim Grøstad wrote:
>> Nothing prevents you from creating your own reference counting mechanism.
>
> A struct wrapper doesn't give the things you need to reliably handle inheritance.

I don't think I suggested using a struct wrapper? :-) That just cause issues with alignment or requires a more complex allocator.

You can either build the refcount into the root class or use an extra indirection like C++'s shared_ptr.