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
