DIP74 - where is at?

[Manu via Digitalmars-d]

On 11 October 2015 at 14:16, deadalnix via Digitalmars-d
<digitalmars-d at 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?