DIP74 - where is at?

[Jonathan M Davis via Digitalmars-d]

On Sunday, 11 October 2015 at 18:52:44 UTC, deadalnix wrote:
> The only rebuttal to all of this is "Walter and I are happy 
> with DIP25, and the fact of the matter", while everybody else 
> is wondering what there is to be happy about.

To be fair, you haven't really said much better. You're claiming 
that it's clear that it's a failure, whereas Andrei is saying 
that he doesn't see a problem with it. No concrete arguments are 
being given. The closest is that you think that the fact that we 
need something like DIP 74 means that DIP 25's advantage of being 
simple is lost and that that somehow shows that DIP 25 is a 
failure.

I don't think that it's at all clear that DIP 25 and DIP 74 are 
even particularly related (and Manu has stated the same). One 
deals with escaping ref parameters (which doesn't involved 
reference counting), whereas the other has to do with reference 
counting. It may very well be that there's a way to cover both 
issues with some sort of ownership model, but that's not clear 
from simply looking at the DIPs or the current discussion. All we 
really have is your assertion that there's a better way.

I'm completely open to there being a better solution than DIP 25 
or DIP 74, but I have yet to see one explained. The only 
alternatives to DIP 74 that I've really seen are suggestions that 
we should be able to do it with library types (like C++ does) and 
not require built-in ref-counting. If there have been any 
in-depth explanations or discussions on how an ownership model 
could solve this, I haven't seen them (though there may very well 
have been one in a previous thread that I missed), so I really 
don't know what that would even entail.

The only place that it's clear to me that an ownership model of 
some kind would be nice would be one related to threads so that 
it we could safely pass mutable data between threads, but 
honestly, I'm okay with it being unsafe to pass mutable data 
across threads. D's threading model makes it pretty easy to get 
that right, and most programs don't need it anyway.

But I have no idea how an ownership model for memory in general 
would work. I'd probably have a much better idea if I had read up 
on Rust (which I really haven't), but every discussion I've seen 
on Rust's model seems to indicate that it gets pretty complicated 
- complicated enough that while it might be more correct, it 
risks being unusable for the average programmer. I don't know how 
true that is, but I do think that if we're going to seriously 
discuss an ownership model in D, we need something concrete 
discuss and debate. I know that writing a DIP takes time (even a 
small one; it surprised me how long it took to write DIP 82 given 
how simple it is, and I've written DIPs before), but if we don't 
have something like that to discuss, then we're just going to be 
going in circles here. If you have a concrete proposal that you 
think would really benefit D, then please write up a DIP for it. 
We could all be way better off for it. Maybe it'll be rejected, 
but without it, we're definitely not going to end up with some 
kind of ownership model like you want. And if you're right, then 
we will be worse off. Concrete proposals are required to have 
concrete discussions and move forward.

- Jonathan M Davis