• Vladimir Panteleev (7/7) Sep 11 2015 https://github.com/D-Programming-Language/phobos/pull/3631
• Brian Schott (3/5) Sep 11 2015 Kill it with fire.
• H. S. Teoh via Digitalmars-d (5/10) Sep 11 2015 +1.
• ixid (3/8) Jan 23 2017 Speaking of killing things with fire (OT) - what's happening with
• Suliman (4/14) Jan 23 2017 I have seen thread about improving tuples, but now I can't find
• jmh530 (3/5) Jan 23 2017 They were deprecated in 2.072.0.
• Daniel N (3/11) Sep 11 2015 maybe if it was moved to DUB, it wouldn't be that disruptive?
• Martin Nowak (2/3) Sep 11 2015 Yes, please add it to http://code.dlang.org/packages/undead at least.
• Jonathan M Davis (36/44) Sep 11 2015 Walter and Andrei publicly agreed at dconf that it should be
• Andrei Alexandrescu (12/29) Sep 11 2015 That's right. I remember I said something like "it deserves a burial".
• Jonathan M Davis (20/25) Sep 11 2015 Makes sense.
• Jacob Carlborg (5/7) Sep 12 2015 I think it can be put in undead as soon as something is deprecated or
• Jonathan M Davis (5/11) Sep 12 2015 That's probably a good policy, but it hadn't occurred to me until
• Seb (5/9) May 01 2016 Even though I don't plan to ever use 'undead', it would be nice
• Jonathan M Davis (5/7) Sep 11 2015 Here's the PR:
• Jonathan M Davis (9/15) Sep 11 2015 And it's now been merged by Walter. So, std.stream and friends
• Jacob Carlborg (12/30) Sep 12 2015 The problem with adding notifications in the documentation is that if a
• Jonathan M Davis (45/56) Sep 12 2015 std.stream got a note in its documentation (something like 3
• Bauss (3/11) May 01 2016 Please yes. Why people still use it is beyond me.
• Seb (8/21) May 01 2016 Baus: I posted to this issue because Andrei suggested to move
• Patrick Schluter (10/32) Jan 23 2017 It would also give a better impression if the sample D programs

"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?

"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.

"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.

ixid <adamsibson protonmail.com> writes:

On Friday, 11 September 2015 at 21:16:06 UTC, Brian Schott 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.

Speaking of killing things with fire (OT) - what's happening with 
the comma operator? I want delicious tuples like Go.

Suliman <evermind live.ru> writes:

On Monday, 23 January 2017 at 17:39:00 UTC, ixid wrote:
 On Friday, 11 September 2015 at 21:16:06 UTC, Brian Schott 
 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.

 Speaking of killing things with fire (OT) - what's happening 
 with the comma operator? I want delicious tuples like Go.

I have seen thread about improving tuples, but now I can't find 
it, could you remember me what people decided about how they 
could look in D?

jmh530 <john.michael.hall gmail.com> writes:

On Monday, 23 January 2017 at 17:39:00 UTC, ixid wrote:
 Speaking of killing things with fire (OT) - what's happening 
 with the comma operator? I want delicious tuples like Go.

They were deprecated in 2.072.0.

http://dlang.org/changelog/2.072.0.html#deprecated_commaexp

"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?

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.

"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

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

"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

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

"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

Seb <seb wilzba.ch> 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).

 Andrei

Even though I don't plan to ever use 'undead', it would be nice 
to have them in dlang's hand, so all committers have access to 
kill more stuff :)

"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

"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

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

"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

Bauss <streetzproductionz hotmail.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?

Please yes. Why people still use it is beyond me.

Seb <seb wilzba.ch> writes:

On Sunday, 1 May 2016 at 14:31:10 UTC, Bauss 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?

 Please yes. Why people still use it is beyond me.

Baus: I posted to this issue because Andrei suggested to move 
undead to dlang and it didn't happen yet. std.stream is already 
set to deprecation in October 2016. This thread is from last 
year. I should have opened a new thread - sorry about that.

 Please yes. Why people still use it is beyond me.

Because they have an existing codebase and don't want to change 
it, see the following issue as an disucssion:

https://github.com/biod/BioD/issues/19

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

On Sunday, 1 May 2016 at 17:06:19 UTC, Seb wrote:
 On Sunday, 1 May 2016 at 14:31:10 UTC, Bauss 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?

 Please yes. Why people still use it is beyond me.

 Baus: I posted to this issue because Andrei suggested to move 
 undead to dlang and it didn't happen yet. std.stream is already 
 set to deprecation in October 2016. This thread is from last 
 year. I should have opened a new thread - sorry about that.

 Please yes. Why people still use it is beyond me.

 Because they have an existing codebase and don't want to change 
 it, see the following issue as an disucssion:

 https://github.com/biod/BioD/issues/19

It would also give a better impression if the sample D programs 
packaged with the dmd compiler didn't use it: d2html.d, htmlget.d 
and wc2.d do not compile because of that (they also have several 
deprecation messages). I just installed 2.73.0 on our Linux 
server at work and to test if everything was ok (I have to 
install by hand because of strange restrictive policies e have 
here) and discovered that the sample programs are completely 
outdated.
If I get the time this week I will try to contribute and fix it.