module std.stream is deprecated - Will be removed by phobos version 2.070

[Jonathan M Davis via Digitalmars-d]

On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev 
wrote:
> https://github.com/D-Programming-Language/phobos/pull/3631
>
> Apparently it was decided at DConf 2015 to remove std.stream 
> and friends from Phobos. But these modules have been left 
> untouched (i.e. they're "stable") for a long time, and there's 
> a lot of D code using them. This decision seems to go in an 
> opposite direction to other recent decisions (i.e. that we stop 
> breaking code). Is everyone (incl. Walter AND Andrei) on board 
> with this?

Walter and Andrei publicly agreed at dconf that it should be 
removed. As I understand it, it was removed from the 
documentation with 2.068 (but not yet deprecated), and now it's 
been deprecated. Now, that being said, I think 2.070 is too soon 
to remove it, because at the rate of releases that Martin is 
targeting, that's maybe 6 months as deprecated, which makes it 
far too easy IMHO for code to go from working to not compiling 
without any warnings in between for someone who's not updating 
their compiler frequently. Normally, the deprecation cycle has 
been approximately one year as deprecated but documented and 
approximately one year as deprecated but undocumented (and then 
the symbol would be removed), so code would continue to work 
as-is for about 2 years once something has been deprecated, which 
is about 4x longer than what std.stream is currently marked for. 
Now, granted, std.stream has essentially been marked as scheduled 
for deprecation for some time now (embarassingly long really), so 
in theory, it's not heavily used, but it's also pretty clear 
based on newsgroup posts and SO and whatnot that it _is_ being 
used on some level in spite of the fact that it's documentation 
says that it's going away.

So, I intend to open a PR to fix the targeted removal time 
(probably this evening) so that it's not quite so quick, but 
it'll still be a year at most, I think, given that it's been 
marked as scheduled for deprecation for so long and is no longer 
in the docs.

After that, as Martin points out, it should go in undead where 
folks can continue to use it if they really want to. But I don't 
think that code should simply stop compiling within a sixth month 
period. I'm all for deprecating and removing stuff that we want 
to get rid of and really don't like keeping it around long term, 
but we need a deprecation cycle that gives folks time to fix 
their code, and sadly, a note in the documentation really doesn't 
seem to be enough of a warning.

- Jonathan M Davis