On Sunday, February 08, 2015 16:43:25 Andrej Mitrovic via Digitalmars-d wrote:
> We still have quite a few features which are listed as to-be-deprecated, but without any dates listed:
>
> http://dlang.org/deprecate.html
>
> So, what's the status of these?

I think that it's a case of us agreeing that we want to do it but no one actually taking care of it. And part of it is a matter of bias by the one making the list. Daniel Murphy went to a lot of effort to get that list put together at one point, and he put an effort into actually moving some of the deprecations along in the compiler, but he didn't agree with all of the items in the list (e.g. IIRC, he thinks that delete should stay), so he didn't make an effort to move all of them along. And no one else has stepped up to do it. I expect that most any of them would stand a good chance of getting changes for them merged though if someone put in the time and effort to create PRs moving them along.

- Jonathan M Davis

"Jonathan M Davis via Digitalmars-d"  wrote in message news:mailman.6286.1423558275.9932.digitalmars-d@puremagic.com...

> I think that it's a case of us agreeing that we want to do it but no one
> actually taking care of it. And part of it is a matter of bias by the one
> making the list. Daniel Murphy went to a lot of effort to get that list put
> together at one point, and he put an effort into actually moving some of the
> deprecations along in the compiler, but he didn't agree with all of the
> items in the list (e.g. IIRC, he thinks that delete should stay), so he
> didn't make an effort to move all of them along. And no one else has stepped
> up to do it. I expect that most any of them would stand a good chance of
> getting changes for them merged though if someone put in the time and effort
> to create PRs moving them along.

Yeah, that's pretty much what happened.  Some I left because they were controversial, some because they were too difficult, some because I just didn't care about them.

Some of the ones on that list have had some work done but haven't been updated.

DDMD currently relies on allocating classes on the stack with 'scope' and overriding without 'override' so I don't want to see those move forward at the moment.

Complex numbers I left alone because I don't know if std.complex is a good enough replacement yet. 

On 10/02/2015 10:59, Daniel Murphy wrote:
> DDMD currently relies on allocating classes on the stack with 'scope'

If something like DIP 69 is implemented, it seems we could support this safely. Then we would only need to deprecate the scope attribute at a class definition.