DIP74 - where is at?

[deadalnix via Digitalmars-d]

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.

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.