DIP74 - where is at?

[Manu via Digitalmars-d]

On 11 October 2015 at 14:25, deadalnix via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> 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.

What's wrong with attributes? I can think of some needed additions to
finish the job, but what would you say is fundamentally wrong with
them as is?


> 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.

What would you do instead? I'm happy with DIP74, and I haven't
followed threads where people have objected and why...?