September 2012 Deprecations

[jmdavis]

This removes all of the deprecated items (save for those in std.string) which were scheduled to be removed in September 2012.

In addition, there is one item which this deprecates (the overload of canFind which takes a predicate), since it was scheduled to be deprecated in September. It's the only thing in this pull request which risks breaking code. Everything else involves removing deprecated stuff.

This should cover everything (other than std.string's functions) which was scheduled to be either removed or deprecated in September.

[andralex]

s/which/that/

[andralex]

I'm coy about breaking more code. Shall we undocumment stuff so new code doesn't use it but old code still has access?

[jmdavis]

The only code which is going to get broken here (unless someone is compiling with -d, which you're not normally supposed to do) is the deprecation of canFind. We can undocument that and not deprecate it if you want, but I see no reason to worry about removing the deprecated stuff.

[andralex]

This pull request cannot be automatically merged.

[andralex]

The other code that will get broken is code that hasn't been tried for a while. That code will be impossible to compile with or without -d.

[jmdavis]

@andralex So, you intend to just keep cruft around in the library, even though it's been deprecated since February? When do we remove it then? We previously agreed that stuff would be scheduled for deprecation for a period of approximately 6 months before being deprecated and that it would be removed approximately 6 months after that. Are you suggesting that we keep them around but undocumented for another 6 months before outright removing them? Or are you thinking that we should be keeping them around indefinitely? It seems incredibly messy to me to keep stuff like this around long term, and it potentially increases maintenance costs.

[jmdavis]

Okay. It's been rebased and changed so that the deprecated stuff is now undocumented and marked for removal in March instead of now (giving it over a year as deprecated before actual removal). The overload for canFind which was scheduled for deprecation in September has now been undocumented and marked for possible deprecation in the future rather than being deprecated now.

d-programming-language.org pull request# 168 is related in that it removes std.ctype from the online docs (though it's now no longer removed from Phobos for the moment).

[DmitryOlshansky]

What about std.regexP ? I thought we were about to remove it years ago.

[jmdavis]

What about std.regexP ? I thought we were about to remove it years ago.

std.file.listdir uses it. It has been deprecated and has been marked for removal in November, but it's still there, and until it goes, we can't get rid of std.regexp. Once std.file.listdir goes, they're both gone. We could remove them both from the docs, but while listdir was marked as scheduled for deprecation for ages, it wasn't actually deprecated until quite recently.

[DmitryOlshansky]

Once std.file.listdir goes, they're both gone. We could remove them both from the docs, but while listdir was marked as scheduled for deprecation for ages, it wasn't actually deprecated until quite recently.

Ah, OK.

[alexrp]

LGTM.

[andralex]

thanks