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