move std.{outbuffer,signals,socket,xml} to undeaD

[wilzbach]

I'd be in favor of finally deprecating all sub-standard phobos module (moving them to https://github.com/dlang/undeaD) to make room for good implementations. Having a vacant place might be more encouraging than to wait for something better to come along.
Of course discussing which modules should be obsoleted is a tricky question.
std.signals
std.xml
std.outbuffer
std.socket
std.json // maybe ;)

http://forum.dlang.org/post/frhctqkzdsiojivpqqap@forum.dlang.org

I think this is a good list to start from 👍
Users should have more than enough time to switch to undeaD and it's really as simple as sed -E 's/std[.](outbuffer|signals|socket|xml)/undead.\1/' -i **/*.d

Sub PRS

• Hide modules from the sidenav on dlang.org
• Move to undeaD

CC @MartinNowak @andralex

[JackStouffer]

I'm against this as is, here's why:

• std.signals can be saved IMO
• Is there something wrong with outbuffer? I've literally never heard anyone complain about it
• std.socket, std.json and std.xml shouldn't be deprecated until we have semi-stable replacements in experimental

[andralex]

We have good opportunities to improve the obsolescence/deprecation process.

The fundamental rule should be: deprecation is accompanied by a better option. There should be a clear, simple, and well-documented migration path from the deprecated facilities to the new ones. There would be reasonable exceptions if e.g. the deprecated facility was hardly used etc.

I've said a number of times (sorry for repeating myself) that we should predate a deprecation cycle by a marginalization process, meaning the documentation has special interior design and UX for features that are still working, but are not the preferred way to do things. Documentation should clarify which better facilities are preferable. That's always the right step. This really does need to happen, can I please summon @MartinNowak and @CyberShadow to help with that.

So let's get better things available before deprecating the not-so-nice things. Thanks.

[ZILtoid1991]

We should wait until we have some semi-decent replacements for these, otherwise a lot of code will be just broken.

To @lodo1995 : Please, hurry up with your project, a faster XML parser would be a pretty good thing for the whole D language.

[CyberShadow]

Having a vacant place might be more encouraging than to wait for something better to come along.

Pretty sure that's fallacious, and might contribute to the replacement being rushed.

std.socket

This will break essentially all D programs that do anything network-related, including even Vibe.d.

[CyberShadow]

and it's really as simple as

Not unless undeaD becomes included with the language - otherwise, there is package management configurations to deal with. If your project is not using Dub, now it either must, or deal with undeaD's directory structure that precludes using it as a package submodule. Many projects which depended only on things in Phobos will now require additional dependencies to build. Etc.

I could see projects being updated with a reasonable amount of effort to get by without std.signals (which hails from the D1 days, before closures) or std.outbuffer (same, predates appender), but there's no easy way to replace std.xml (without new third-party dependencies) or std.socket (at all).

[andralex]

Related: we may be able to help the deprecation of the string pattern matching by means of changelog and documentation examples.

[JackStouffer]

@andralex Yes, that's on my todo list this weekend.

[MartinNowak]

Point was we're not seeing decent replacements, making space would hopefully be encouraging to contributors. As long as new people keep using std.xml and std.socket, we're causing more grief and accumulate more crappy D legacy code in our ecosystem.

Yes, marking modules unstable/outdated/deprecated as is done in NodeJS's documentation is simple and effective to inform people.

[andralex]

Point was we're not seeing decent replacements, making space would hopefully be encouraging to contributors.

That's a hypothesis. What evidence would substantiate it?

Yes, marking modules unstable/outdated/deprecated as is done in NodeJS's documentation is simple and effective to inform people.

Great, I think starting with documentation should be the official way of implementing all deprecations.

[wilzbach]

Yes, marking modules unstable/outdated/deprecated as is done in NodeJS's documentation is simple and effective to inform people.
Great, I think starting with documentation should be the official way of implementing all deprecations.

Okay, I gave this a try: dlang/dlang.org#1778
Once agreed / merged, we can slap a simple Ddoc macro like $(COMPATIBILITY_BOX_0) on all modules.