On 11 October 2015 at 15:57, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote:
>>
>> On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:
>>>
>>> [...]
>>
>>
>> Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this?
>
>
> You can. It is not safe, but it will do. Using type qualifier, one can get better than C++'s shared_ptr already.

How?

On 11 October 2015 at 16:06, Freddy via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote:
>>
>> Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this?
>
>
> Also how will DIP74 work with incremental compilation?
> ---
> extern (D) class RcClass;
>
> void func(RcClass a)
> {
>     //opps
>     auto b = a;
>     return;
> }
> ---

extern (D) class RcClass
{
  void opInc();
  void opDec(); // or whatever they're called
}

?

On 11 October 2015 at 16:17, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 11 October 2015 at 06:10:32 UTC, Jonathan M Davis wrote:
>>
>> On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote:
>>>
>>> On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:
>>>>
>>>> [...]
>>>
>>>
>>> Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this?
>>
>>
>> alias is problematic, because it allows the class reference to escape. opDispatch doesn't have that problem, though there may be other complications that it introduces (I don't know). It does get kind of complicated though when you consider member functions which return the a reference to the object and things like that. So, while it's generally feasible, it's not that hard for it to become unsafe. How much that matters is debatable, but it could make it so that reference counting classes is infeasible in @safe code.
>>
>> - Jonathan M Davis
>
>
> Ok dispatch has that problem. You can escape the this pointer from within member functions. Always. There is no @safe reference counting without language support. Either the RC is backed into the language (DIP74) or ownership is baked into the language, so that RC can be baked into the library.

Ownership is only part of the problem (and I support your ideas about ownership, I think D is completely going the wrong way on ownership). There is still the problem that the inc/dec primitives need to be known for the compiler to optimise. Constructors/destructors don't do it semantically. That seems to be what DIP74 is introducing, and even if the ownership problems were addressed/improved, DIP74 would just remap to those concepts. We still need the inc/dec primitives either way.

On 10/11/15 7:25 AM, deadalnix wrote:
> On Sunday, 11 October 2015 at 02:01:09 UTC, Jonathan M Davis wrote:
>> AFAIK, Walter and Andrei are still in favor of something that's at
>> least similar to DIP 74. Andrei made a comment in a thread just the
>> other day that indicated that he was in favor of having a way to build
>> reference counting into classes. So, I don't know why you think that
>> it's not going to be implemented other than the fact that it hasn't
>> been implemented yet. It wouldn't surprise me if the DIP needed some
>> tweaking though.
>>
>
> Yes, and that's quite ridiculous. I mean this is getting into ridiculous
> ego battle.

It's unlikely that adding inflammation to this would help too much - sticking to the technical points is more helpful.

You're saying that as far as you can tell you have made the perfect argument in favor of your proposed approach (have you written it up as a DIP?) and that essentially there is no reasonable way your idea could not be accepted. If you failed to raise the response you think that proposal deserves, getting emotional about it can't possibly be more productive than reiterating the technical point.

We're all on the same boat. We want to make D better. Let's.


Andrei

On 10/11/15 9:48 AM, Manu via Digitalmars-d wrote:
> C++ basically implemented rval-references to
> improve (not solve) the RC problem...

Interesting, haven't heard of this viewpoint. Could you please give detail on that? -- Andrei

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@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. 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.

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.

- Jonathan M Davis

On Sunday, 11 October 2015 at 06:48:54 UTC, Manu wrote:
> I don't really see that DIP25 and DIP74 are particularly closely related.

Ho they are. It is all about ownership.

> DIP25 is a lame cop-out with respect to scope. I was a major backer of
> a proper scope implementation, and given that, I don't/didn't support
> DIP25 at all.
>

DIP25 being a sorry excuse for ownership is the very reason DIP74 is needed. Rust can do reference counting just fine all in library without need for core language support.

> DIP74 on the other hand introduces 2 magic functions that the compiler calls as the appropriate moments to implement ref counting. The implementation is somewhat detail, theoretically changeable in the future, but I think language support for ref-counting primitives is critical for ref counting to be efficient and simple. Look at C++, and we see a disaster. C++ basically implemented rval-references to improve (not solve) the RC problem... we don't have rval-ref's in D, so we're screwed from the library angle.
>

C++ ref counting is not slow for the reasons you think it is. ARC is overly complex and also not as fast as you think it is.

First, they are slow because in C++ (or ObjC), you don't know what is shared and what isn't. As a result, you got to go the pessimistic road and use thread safe ref counting. This can be a solved problem in D purely using the type qualifier.

Second, exceptions. Their unwinding makes pair of inc/dec hard to recognize, plus now cleanup is need at pretty much every frames, meaning incredibly slow exceptions + various control flow optimization that aren't possible anymore (tail call being one of them).

One that one, nobody has a solution. Not ARC (that's why swift does not have exception), not C++ and not us. IMO the obvious solution here is to allow ourselves to leak on unwind and rely on the GC. Yes, sometime the GC is best. That being said, it is up to the application to decide if leaking is acceptable or not, and so this can't be baked in the language (this also means that the user must be in charge the of deallocation policy, which puts a major dent into DIP74).

The 3rd problem is safety. This is where ownership shines.

The 4th problem is elision of refcount operations when not needed. Some thing, ownership can solve this. No need to do refcount operations when not necessary.

The compiler is perfectly able to optimize pairs of inc/dec granted it has the rights infos. And a proper ownership system provide the right infos.

> Yup, I was firmly behind scope (ie, borrowing), but that was
> destroyed, and DIP25 kinda cements the death of that :(
>

It is implemented with a flag. That allowed us to try it and get real life experience. That is a good thing. We aren't committed to it at this stage. And now we have actual experimentation that shows that it is too underpowered to be really useful. The smart move here is to admit defeat and reconsider.

On Sunday, 11 October 2015 at 07:01:35 UTC, Manu wrote:
> On 11 October 2015 at 15:57, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
>> On Sunday, 11 October 2015 at 05:52:45 UTC, Freddy wrote:
>>>
>>> On Saturday, 10 October 2015 at 23:25:49 UTC, Manu wrote:
>>>>
>>>> [...]
>>>
>>>
>>> Speaking of DIP74 can't we just wrap a class in a struct with use reference counting with and use alias this?
>>
>>
>> You can. It is not safe, but it will do. Using type qualifier, one can get better than C++'s shared_ptr already.
>
> How?

In C++, you need to assume things are shared, and, as such, use thread safe inc/dec . That means compiler won't be able to optimize them. D can do better as sharedness is part of the type system.

On 11 October 2015 at 17:10, Andrei Alexandrescu via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On 10/11/15 9:48 AM, Manu via Digitalmars-d wrote:
>>
>> C++ basically implemented rval-references to
>> improve (not solve) the RC problem...
>
>
> Interesting, haven't heard of this viewpoint. Could you please give detail on that? -- Andrei

Yeah, that is a terrible claim, but that do offer some advantage (in
this situation as with others).

The language doesn't support ref counting; constructors/destructors are a pretty crude mechanism to implement them, since they don't model the ref-counting pattern but a superset, which technically allows it to work, but it's pretty lame and inefficient to do ref-counting this way, and it's impossible for code (or the compiler) to distinguish between actual ref-counting events and must behave conservatively. rvalue-references allow the language to elide some unnecessary assignment logic, which can be further used to perform some inc/dec elision, but it starts to get extremely complex at this point, and it still doesn't do the trick. It's a sort of band-aid, but certainly not just for RC.

On Sunday, 11 October 2015 at 07:08:26 UTC, Andrei Alexandrescu wrote:
> On 10/11/15 7:25 AM, deadalnix wrote:
>> On Sunday, 11 October 2015 at 02:01:09 UTC, Jonathan M Davis wrote:
>>> AFAIK, Walter and Andrei are still in favor of something that's at
>>> least similar to DIP 74. Andrei made a comment in a thread just the
>>> other day that indicated that he was in favor of having a way to build
>>> reference counting into classes. So, I don't know why you think that
>>> it's not going to be implemented other than the fact that it hasn't
>>> been implemented yet. It wouldn't surprise me if the DIP needed some
>>> tweaking though.
>>>
>>
>> Yes, and that's quite ridiculous. I mean this is getting into ridiculous
>> ego battle.
>
> It's unlikely that adding inflammation to this would help too much - sticking to the technical points is more helpful.
>
> You're saying that as far as you can tell you have made the perfect argument in favor of your proposed approach (have you written it up as a DIP?) and that essentially there is no reasonable way your idea could not be accepted. If you failed to raise the response you think that proposal deserves, getting emotional about it can't possibly be more productive than reiterating the technical point.
>
> We're all on the same boat. We want to make D better. Let's.
>
>
> Andrei

No I'm not saying I've made the perfect argument.

I'm saying that DIP 25 was implemented and showed that it was too limited. The various experiment with it showed that is wasn't enough (ref counted objects) or required to jump though a lot of hoops for somewhat disappointing result (ref counted arrays).

DIP74 is a direct result of DIP25 limitations. I think we should start by acknowledging that the DIP25 experiment was not a success before taking it for granted and proceed.

I do think a buffed up version of DIP25 would make DIP74 obsolete (or implementable as a library).