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

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

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

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

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 :)

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.

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

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.

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.

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?