Show warnings about outdated Phobos modules

[wilzbach]

As moving old & ugly Phobos modules to undeaD doesn't seem to be an option for now, let's at least try to warn the user.
I used the same message as we already display on std.xml.

Are there other modules that you would like to be included on this list?

Previous discussion: dlang/dlang.org#1778

[dlang-bot]

Thanks for your pull request, @wilzbach!

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

[wilzbach]

CC @edi33416

[wilzbach]

I actually would like to go with red here as it's like std.xml on the hit list and even has an excellent, well-maintained replacement!

[andralex]

The solution is to bring the replacement into std.

[wilzbach]

This won't happen:

http://docs.python-requests.org/en/master/dev/philosophy/#standard-library

Requests has no active plans to be included in the standard library. This decision has been discussed at length with Guido as well as numerous core developers.
Essentially, the standard library is where a library goes to die. It is appropriate for a module to be included when active development is no longer necessary.

(philosophy is similar)

See also: ikod/dlang-requests#10

[andralex]

I'm not keen about this.

• The messages making remarks about work in progress on collections are not actionable.
• The messages sending people to third-party alternatives are actionable but seem out of place and with no precedent. For example the page on C++'s std::unordered_map there's no "check out Google sparsehash for much better and much faster alternatives". Even more poorly done parts of C++ std such as the localization library do not come with recommendations to avoid in favor of e.g. ICU. As far as I know other languages' standard library official documentation also avoid placing judgment on the artifacts they offer. I don't see why we need to be the only ones to wear the hair shirt.

[jmdavis]

On the one hand, it does kind of make sense to point folks to better alternatives, but on the other hand, it's downright weird to have something in the standard library that we basically say not to use and then point to 3rd party libraries. It's one thing to replace something in the standard library with something else. It's quite another to tell folks to go use 3rd party libraries but leave the supposedly bad solution in the standard library.

At the same time, I don't know what we really should be doing with some of these, because for some of them, it seems pretty unlikely that we're going to end up with replacements in Phobos. Even getting a replacement for std.xml seems pretty iffy, and there's a package up on code.dlang.org for a GSoC project that was supposedly going to replace it (though since its maintainer seems to be MIA, that project is looking rather dead right now).

However, it is perfectly normal to have 3rd party alternatives exist for standard library constructs where the 3rd party alternative is considered by many to be superior. So, unless the Phobos solution is so bad that we really need to be telling folks to not use it (in which case, we really should look at removing it and putting it in undead), I'm not sure that it makes a lot of sense to be doing something like this. I mean, we put a note on std.xml to warn folks because a replacement was supposed to be coming, and we wanted folks to be aware that they were going to have to change their code eventually, but that was years ago and we still don't have a replacement, which looks that much worse than having a bad API in the first place. And for the others, except for std.container, there isn't even a consensus that we plan on replacing them.

Sure, I hate std.socket. I even have a partially completed replacement that will be @nogc for at least the low level API, but it's not going to be done for a while, and I'm not sure that I even want to get try and get it in Phobos, because then I don't control it anymore, and it's going to include SSL support, which realistically means relying on 3rd party libraries, which I don't think is appropriate for the standard library. And no one else has stepped forward to replace it. In fact, almost no one seems to want to write modules to go in Phobos at this point. Anyone doing much of anything just puts it up on code.dlang.org. So, I don't think that it's reasonable at this point to expect that replacements will emerge for all of these modules, and I have to agree with Andrei that it just looks bad to be telling folks not to use something that's in the standard library.

I think that we should either decide that a module is so bad that it needs to be removed and put in undead, or we should just leave it. Having something is still often better than nothing, even if it's subpar. And if a replacement does come along later, then we can look at going through the process of replacing it. But putting labels on the top telling folks that the code is bad and that they should go use a 3rd party alternative just looks bad - especially when we have a clear track record which indicates that it's unlikely that a replacement is going to happen. A few modules have been replaced over the years (e.g. std.datetime and std.regex are replacements for older modules), but when we say that we want to replace something, and no one has stepped up to replace it, it consistently sits there for years without getting replaced. Even when someone has stepped up, they often disappear before they're done. So, realistically, I think that we need to just learn to live with some of these modules being in the standard library and letting folks use them, much as that's not ideal. Anyone who is then not happy with any of the modules can then look for alternatives on code.dlang.org.

[wilzbach]

I think that we need to just learn to live with some of these modules being in the standard library and letting folks use them, much as that's not ideal. Anyone who is then not happy with any of the modules can then look for alternatives on code.dlang.org.

I just saw this thread on the NG and it shows perfectly what happens if we don't deprecate the old and ugly modules (or at least hide their documentation): people start using them, get frustrated by their brokenness, associate this with D and move on.

[braddr]

So.. this going to move forward or be closed. Seems somewhat pointless to leave it unresolved.

[ghost]

std.uri : it only supports a subset of the URI standard. Just the name is a scam.

[MetaLang]

@andralex looks like we need a definite decision on this. Please close or merge.

[joakim-noah]

I like this PR. It looks out for the user, who is likely not tracking thousands of forum posts to know what not to use or watch out for. A warning doesn't have to be actionable, a head's up is good enough. As for it looking bad, realistically there are outdated modules in Phobos that we'd like to replace with better outside modules, but only don't because there is legacy code relying on it and the outside authors don't want to go through the Phobos review gauntlet, at least not yet. Better not to onboard more new users onto those outdated modules and have them try out the better outside modules instead.

If other stdlibs are not honest enough to do this, all the more reason for Phobos to do what's best for the user and differentiate itself.

[wilzbach]

Yet another example of someone bumping into an old, unmaintained module and taking its quality for granted: http://forum.dlang.org/thread/zkdkpjcxnuvyihdvvzbk@forum.dlang.org

[MartinNowak]

I think the real question is really just which modules. Hardly anyone would disagree about deprecating std.signals and maybe std.outbuffer. So maybe just use that box for deprecated modules.

The other modules in this PR are usable, albeit not great. And indeed it's unclear when and whether replacements will be available.

I'd also agree to rather make code.dlang.org more prominent on the website and better explorable than pointing people from the standard library to 3rd party libs.

[MartinNowak]

Going to close this until the discussion is resolved.