DIP74 - where is at?

[deadalnix via Digitalmars-d]

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.

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.

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.

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.