www.digitalmars.com         C & C++   DMDScript  

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

reply "Vladimir Panteleev" <thecybershadow.lists gmail.com> writes:
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?
Sep 11 2015
next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev 
wrote:
 Apparently it was decided at DConf 2015 to remove std.stream 
 and friends from Phobos.
Kill it with fire.
Sep 11 2015
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Sep 11, 2015 at 09:16:05PM +0000, Brian Schott via Digitalmars-d wrote:
 On Friday, 11 September 2015 at 20:29:56 UTC, Vladimir Panteleev wrote:
Apparently it was decided at DConf 2015 to remove std.stream and
friends from Phobos.
Kill it with fire.
+1. T -- Guns don't kill people. Bullets do.
Sep 11 2015
prev sibling next sibling parent reply "Daniel N" <ufo orbiting.us> writes:
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?
maybe if it was moved to DUB, it wouldn't be that disruptive?
Sep 11 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 09/11/2015 11:47 PM, Daniel N wrote:
 maybe if it was moved to DUB, it wouldn't be that disruptive?
Yes, please add it to http://code.dlang.org/packages/undead at least.
Sep 11 2015
prev sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
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
Sep 11 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/11/2015 07:06 PM, Jonathan M Davis wrote:
 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.
That's right. I remember I said something like "it deserves a burial". It was on the spur of the moment; after that I figured I should have better said "Does it prevent anyone from writing good code? It's not in the documentation, so no new code will use it. Leave it be for now, no reason to do anything for a while".
 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.
Undead is a great idea at least because it's a good place to park documentation for legacy code. In fact we should move undead to the dlang repo (now it's in digitalmars). Let's let std.stream lay low for a while more, it's really not preventing anything from happening. Andrei
Sep 11 2015
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 11 September 2015 at 23:32:01 UTC, Andrei Alexandrescu 
wrote:
 Undead is a great idea at least because it's a good place to 
 park documentation for legacy code. In fact we should move 
 undead to the dlang repo (now it's in digitalmars).
Makes sense.
 Let's let std.stream lay low for a while more, it's really not 
 preventing anything from happening.
Given that it's not in the docs, I do think that it should be deprecated (like it is now), but I definitely think that it should stick around longer than just 2.070. I don't like the idea of leaving deprecated code around long term, but we definitely want to give folks time to transition their code and reduce the risk of them missing the deprecation messages entirely because they waited half a year to update their compiler. Though, now that I think about it, we should probably also put it in undead now (assuming that undead doesn't use std, which I assume it doesn't) - but still leave it in Phobos for the moment as well. Then folks that want to keep using it can just switch to the undead repo and not see the deprecation messages anymore if they don't intend to actually change their code so that it doesn't use std.stream, and those that haven't updated their code or switched to using undead would still see the deprecation messages. - Jonathan M Davis
Sep 11 2015
parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-12 03:23, Jonathan M Davis wrote:

 Though, now that I think about it, we should probably also put it in
 undead now.
I think it can be put in undead as soon as something is deprecated or to-be-deprecated in the documentation. -- /Jacob Carlborg
Sep 12 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 12 September 2015 at 14:26:10 UTC, Jacob Carlborg 
wrote:
 On 2015-09-12 03:23, Jonathan M Davis wrote:

 Though, now that I think about it, we should probably also put 
 it in
 undead now.
I think it can be put in undead as soon as something is deprecated or to-be-deprecated in the documentation.
That's probably a good policy, but it hadn't occurred to me until we were discussing it here. - Jonathan M Davis
Sep 12 2015
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Friday, 11 September 2015 at 23:06:16 UTC, Jonathan M Davis 
wrote:
 So, I intend to open a PR to fix the targeted removal time 
 (probably this evening) so that it's not quite so quick
Here's the PR: https://github.com/D-Programming-Language/phobos/pull/3647 - Jonathan M Davis
Sep 11 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 12 September 2015 at 04:50:06 UTC, Jonathan M Davis 
wrote:
 On Friday, 11 September 2015 at 23:06:16 UTC, Jonathan M Davis 
 wrote:
 So, I intend to open a PR to fix the targeted removal time 
 (probably this evening) so that it's not quite so quick
Here's the PR: https://github.com/D-Programming-Language/phobos/pull/3647
And it's now been merged by Walter. So, std.stream and friends will be around as deprecated but undocumented until about October of next year. And they're now in undeaD as well, so anyone who wants to continue to use them can just pull in undeaD instead and adjust their imports. So, std.stream is finally on the way out as planned but not quite so abruptly. - Jonathan M Davis
Sep 11 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-09-12 01:06, Jonathan M Davis wrote:

 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.
The problem with adding notifications in the documentation is that if a user already has implemented code that uses the particular model and have no need to change the code. Or the user already is familiar with the module there's no reason to read the documentation to see the notification or to notice the documentation is gone. It only (hopefully) prevents new users to use the module. Would it be better to add the deprecation immediately and let be deprecated for a longer period? Or use something like 'pragam(msg, "WARNING: deprecated ...")' if someone is using the "-de" flag. -- /Jacob Carlborg
Sep 12 2015
parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Saturday, 12 September 2015 at 14:24:21 UTC, Jacob Carlborg 
wrote:
 The problem with adding notifications in the documentation is 
 that if a user already has implemented code that uses the 
 particular model and have no need to change the code. Or the 
 user already is familiar with the module there's no reason to 
 read the documentation to see the notification or to notice the 
 documentation is gone.

 It only (hopefully) prevents new users to use the module.

 Would it be better to add the deprecation immediately and let 
 be deprecated for a longer period? Or use something like 
 'pragam(msg, "WARNING: deprecated ...")' if someone is using 
 the "-de" flag.
std.stream got a note in its documentation (something like 3 years ago) rather than being deprecated, because we didn't have a replacement yet. We just knew that we definitely wanted to replace it. But we have yet to actually come up with a replacement, and when it was brought up at dconf that the note had been on std.stream for years and yet the module was still there, Andrei said that we should just kill it and that maybe this was a sign that streams weren't all that important. So, we're now actually deprecating it even though we don't have a replacement yet. It used to be that marking something as deprecated immediately made that code fail to compile, which is why we used to mark stuff as "scheduled for deprecation" in its documentation for a while before actually deprecating it, but deprecated was fixed a while ago so that it doesn't result in a compilation error by default (hence the -de flag that you mentioned), and when that change was made, we stopped marking stuff as "scheduled for deprecation." Normally, what we've been doing for a while now is to just immediately deprecate a symbol (or module) and then wait about a year before removing it from the docs, and then wait about another year before removing it from the code. So, the result is that existing code has about two years to be changed before it'll stop compiling due to the symbol going away. It's just that anyone compiling it will be bugged by deprecation messages unless they use a flag to shut them off (which they shouldn't, because then they'll miss all deprecation messages, but folks are free to shoot themselves in the foot if they really want to). So, at this point, there really isn't much point in general in saying anything in the documentation before deprecating a symbol, and we haven't been doing that. The one exception that's come up is that deprecating a symbol and introducing its replacement in the same release causes problems for folks who need their code to build with both the current release and master (as is the case with Vladimir). So, in a few cases, we've marked a symbol as scheduled for deprecation when we add its replacement and then have deprecated it in the next release and continued the deprecation cycle as normal. But most of the time, we've just gone straight to deprecated, and we aren't doing a lot of deprecating these days, so it's nowhere near the issue it was when we were doing mass renamings and whatnot several years ago. - Jonathan M Davis
Sep 12 2015