DIP74 - where is at?

[Manu via Digitalmars-d]

On 11 October 2015 at 17:16, Jonathan M Davis via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On Sunday, 11 October 2015 at 06:55:50 UTC, Manu wrote:
>>
>> On 11 October 2015 at 14:35, Jonathan M Davis via Digitalmars-d
>> <digitalmars-d at puremagic.com> wrote:
>>>
>>> On Sunday, 11 October 2015 at 04:16:11 UTC, deadalnix wrote:
>>>>
>>>>
>>>> If we go these DIP road, there is no coming back and this will get in
>>>> the way of a principled approach.
>>>
>>>
>>>
>>> Then come up with an alternative DIP which shows a better way to solve
>>> this. As it stands, it looks likely that we'll end up with some form of DIP
>>> 74, and if you have a better proposal, then now is probably the time to do
>>> it.
>>>
>>> Personally, I obviously haven't been following this closely enough,
>>> because I don't understand why something like RefCounted can't be made to do
>>> what we need with regards to reference counting and classes. It does get a
>>> bit nasty when inheritance and whatnot get involved, but C++ was able to
>>> solve that easily enough, and we should be able to do the same.
>>
>>
>> C++ didn't solve anything(?). C++ doesn't support ref-counting at all!
>> shared_ptr is not a part of the language, or a proper ref counting
>> mechanism. It's just a hack; it's awkward, and really inefficient (the
>> compiler can't optimise it).
>> ARC requires language knowledge. I don't know what language primitives
>> can possibly allow the compiler to do proper ref fiddling optimisation
>> with a lib?
>
>
> Ref-counting with shared_ptr works just fine. It just doesn't optimize out
> any of the incrementing or decrementing.

I wouldn't call that 'working', I'd call that 'grossly over-working' at best.
I'd personally diagnose signals firing at improper times to be a bug,
and that's effectively what we have ;)

I think it's absolutely worthwhile that a language should know that
refcounting is a thing, and what the proper handling is. I don't know
any way to model it accurately without language support.

> And while having those optimized
> out would be nice, I don't think that in and of itself that makes it worth
> having ref-counting in the language rather than in the library.

For real? If you're handling ref-counted objects, ref-fiddling often
completely overwhelms your code at the interface level, and god forbid
you have some sort of adaptation layers, shims, small temporaries,
call-throughs, or iterations.
Problem is amplified big time if your ref-counting functions are
foreign library functions, which is pretty common in C api's. These
functions need to be wrapped with a primitive that properly knows when
the functions should be called.

I'm seeing objects with RC==8+ or so across one event handling call-tree.

> Maybe C++ ref-counting hasn't work well for your use cases, but I've used it
> for years, and it's worked great for what I've needed.

Sure. If you don't care, I'm sure it's fine. But I don't feel it's
reasonable to say C++ has ref counting. You might as well say "C++ has
garbage collection" (which is probably actually more true than this)
;) ... Objective-C supports ref counting.