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?

On Sunday, 11 October 2015 at 05:18:26 UTC, Jonathan M Davis wrote:
> Well, if they won't listen, they won't listen. And if they're wrong, we'll be worse off for it. Unfortunately, I wasn't involved in those discussions and haven't looked into DIP 25 much (I was too busy at the time of the major discussion for it IIRC). So, I'm not familiar enough with it to have a properly informed opinion. But convincing Walter and Andrei is typically pretty difficult. They do come around eventually at least some of the time though. So, as frustrating as such discussions can be, they do bear fruit at least some of the time (whether it's by them convincing you or by you convincing them). And since DIP 25 has only been implemented with a flag rather than adding it to the language proper yet, there's still time to convince them before we're fully committed to it - as difficult as convincing them may be.
>
> - Jonathan M Davis

Truth be told at the time I was doubtful a DIP25 like approach, but willing to give it a try. They had me convinced of that much. Maybe that wasn't that powerful, but maybe that was powerful enough for basics uses cases and would cut it.

Seeing what comes out of it confirmed that no, it won't, and once you get DIP25 + DIP74 you are in the same ballpark as other proposals in term of language additions, but barley measure in terms of capabilities.

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.

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;
}
---

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

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.

On 11 October 2015 at 14:16, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> wrote:
> On Sunday, 11 October 2015 at 01:48:05 UTC, Manu wrote:
>>
>> I'm rather in favour of DIP74... what's unprincipled about it? What would you do instead?
>>
>
> Well, DIP25 and DIP74 are ad hoc adding to the language to support specific use cases. I think the whole thing is wrong headed.

I don't really see that DIP25 and DIP74 are particularly closely related.
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.

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.


> Ideally when designing the language you want to have a set of principled tools added to the language that enable the uses cases you want. You don't bake the uses cases into the language. Inevitably, new use cases crop up, they get poor support and/or ends up as new addition into the language, with more and more complexity along the road.
>
> The problem at hand is fairly well know at this stage: it is ownership. Everything else can be done as library.

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

That said, this has nothing to do with ref-counting. Scheduling (and optimising) calls to inc/dec is not something I've seen language tools implement efficiently. The compiler needs to understand that it has the authority to elide pairs appropriately, even when the optimiser is unable to see the code that implements the inc/dec pair. I can't think of any way to do this without a foundation like DIP74...?


> The DIP25/DIP74 combo is quite limited. It doesn't solve ownership transfer, it forces an ownership model on the user, it doesn't reduce friction with the GC, it doesn't allow to delegate memory management to the user (the only kind that make sense). and worse, as these issue aren't orthogonal to these DIP, they actively make these problem harder to solve.

How? I don't see how opInc/opDec really changes the underlying type system or allocations mechanisms much, it just gives the compiler the opportunity to understand the optimise reference counting, which is a well understood problem.


> Solution have been proposed to solve these. It is not hardly new. I mean C++
> obviously got the hint:
> https://github.com/isocpp/CppCoreGuidelines/blob/09aef9bd86d933bc1e1ffe344eb2e73d2de15685/docs/Lifetimes%20I%20and%20II%20-%20v0.9.1.pdf
>
> If we go these DIP road, there is no coming back and this will get in the way of a principled approach.

DIP25 is done, I rejected it but it's done... I don't really see how DIP74 ruins anything?

On 11 October 2015 at 14:25, deadalnix via Digitalmars-d <digitalmars-d@puremagic.com> 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. Remind of that concept vs static if grand debate, the peak of ridiculousness (everybody know you don't need type system when you have if statement and vice versa, so the same must be true at compile time as well).
>
> When a direction obviously showed to be the wrong one, the rational thing to do is not to double down in order to not admit one is wrong.
>
> DIP25 implementation showed a ton of limitations and pitfalls. It isn't even possible to do a slice type with eager deallocation, just one with deferred deallocation, with complex strategies to make it all safe.
>
> It is a sign of a poorly thought out language addition.
>
>> It wouldn't surprise me though if something like the possibility of
>> getting D into another company relied on something like DIP 74 helped push
>> it along and got it sorted out faster. Clearly, Walter and Andrei think that
>> it's an issue and have done some work on it at the theoretical level, but I
>> don't know where it sits on their priority list. And even if DIP 74 were
>> fully sorted out tomorrow, it would still require Walter or someone else
>> actually implementing it, and that's probably not a small undertaking.
>>
>> - Jonathan M Davis
>
>
> Yeah, we saw what happens with attributes. Don't get me wrong, attribute are a very useful addition to the language and all, but the current implementation has some serious flaws, none of them could be addressed as it was pushed out of the door in an inconsequent manner. The fact that dlang.org is littered of antipaterns usage of them is quite telling.

What's wrong with attributes? I can think of some needed additions to finish the job, but what would you say is fundamentally wrong with them as is?


> I'm all for pushing useful feature, especially if that can drive adoption in a company. But using it as an excuse for releasing half backed feature is VERY short sighted.

What would you do instead? I'm happy with DIP74, and I haven't followed threads where people have objected and why...?

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?

On 11 October 2015 at 15:52, Freddy via Digitalmars-d <digitalmars-d@puremagic.com> 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?

Because the language doesn't have ref counting. And... no.
If the 'solution' D offers is more complicated than C++, why would I
leave C++? I certainly won't win over any new D users when I show them
how awesome D is at making their already horribly complex code even
worse.