"Ghosting" is a current age term for the notion of ceasing all contact with someone.

I propose we define and use "ghosting" for language and library features. It would be a distinct term from "deprecation".

Ghosting would go like this:

* We develop a good definition for the term.

* We add a glossary entry with the definition to the website.

* Once a feature is ghosted, the following happens:

- All documentation and examples of the feature get moved to a distinct portion of the website. It would feature its own URL base (maybe its own domain or subdomain), a distinct, somewhat unpleasant styling, and would use as heading a non-equivocal warning that the feature has been ghosted and other feature(s) should be used instead.

- The links to the ghosted feature from normal code will be minimal and marginalized (gray text, small font, etc) and accompanied by a "ghosted!" warning. We could brand this with some special font, a ghost icon, etc so people are constantly queued they are exploring a part of the language not intended for new code.

- All bugs related to the feature will be closed as "resolved wontfix".

- The feature will keep on working as is, but new compiler and library code will not use it.

Why create a new term no one will understand? This is basically deprecating a feature and then not removing it. If you are going to close all the issues and then not fix say memory safety issues, why not just remove it so no one uses it. This is when having a proper language versioning scheme would come in handy. So that when you deprecate a feature you don't have to make up a term for it. You just remove it from the next version of the language.

On 9/20/2020 7:38 PM, Avrina wrote:
> why not just remove it so no one uses it.

Because legacy code will use it. Removing features has been a constant source of irritation to users, and they're right.

On Monday, 21 September 2020 at 02:43:57 UTC, Walter Bright wrote:
> On 9/20/2020 7:38 PM, Avrina wrote:
>> why not just remove it so no one uses it.
>
> Because legacy code will use it. Removing features has been a constant source of irritation to users, and they're right.

Maybe "legacy features" is good name

On Mon, Sep 21, 2020 at 03:00:09AM +0000, Ben Jones via Digitalmars-d wrote:
> On Monday, 21 September 2020 at 02:43:57 UTC, Walter Bright wrote:
> > On 9/20/2020 7:38 PM, Avrina wrote:
> > > why not just remove it so no one uses it.
> > 
> > Because legacy code will use it. Removing features has been a constant source of irritation to users, and they're right.
> 
> Maybe "legacy features" is good name

Yeah, no need for a new strange term that people don't understand; "legacy features" is a good existing term that people will immediately understand.

I'd even go as far as saying that after a deprecation period of a suitable length, we should just remove the documentation altogether, but just stop short of actually removing the feature.  That way, old code will continue to work, but new code will stop using it because people won't find the documentation for it anymore.


T

-- 
The problem with the world is that everybody else is stupid.

On Monday, 21 September 2020 at 04:30:01 UTC, H. S. Teoh wrote:
> I'd even go as far as saying that after a deprecation period of a suitable length, we should just remove the documentation altogether, but just stop short of actually removing the feature.  That way, old code will continue to work, but new code will stop using it because people won't find the documentation for it anymore.
>
>
> T

It sounds like we just need a switch for the ddoc generator? Whether to generate documentation for @deprecated symbols or not.

On Monday, 21 September 2020 at 04:30:01 UTC, H. S. Teoh wrote:
> I'd even go as far as saying that after a deprecation period of a suitable length, we should just remove the documentation altogether, but just stop short of actually removing the feature.  That way, old code will continue to work, but new code will stop using it because people won't find the documentation for it anymore.

That's maintenance nightmare, if someone (non-author) need to fix bugs in the legacy code later, but cannot find the doc anymore.

On Mon, Sep 21, 2020 at 05:38:59AM +0000, mw via Digitalmars-d wrote:
> On Monday, 21 September 2020 at 04:30:01 UTC, H. S. Teoh wrote:
> > I'd even go as far as saying that after a deprecation period of a suitable length, we should just remove the documentation altogether, but just stop short of actually removing the feature.  That way, old code will continue to work, but new code will stop using it because people won't find the documentation for it anymore.
> 
> That's maintenance nightmare, if someone (non-author) need to fix bugs in the legacy code later, but cannot find the doc anymore.

Hmm, true.  So maybe moving the doc to a big ugly page with warnings about unsupported legacy features would still work best.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On 9/20/2020 9:30 PM, H. S. Teoh wrote:
> I'd even go as far as saying that after a deprecation period of a
> suitable length, we should just remove the documentation altogether, but
> just stop short of actually removing the feature.  That way, old code
> will continue to work, but new code will stop using it because people
> won't find the documentation for it anymore.

Having secret undocumented features just winds up irritating people.

On Monday, 21 September 2020 at 02:43:57 UTC, Walter Bright wrote:
> On 9/20/2020 7:38 PM, Avrina wrote:
>> why not just remove it so no one uses it.
>
> Because legacy code will use it. Removing features has been a constant source of irritation to users, and they're right.

I wish D would stop trying to be this or that, and finally settle on its identity.

People that use D don't do it because they want a flawless upgrade path and everything to just be the same 10 years from now. If you want this, you just stick with one of the big languages. This is not just an hypothesis out of thin air, look at the community survey: https://rawgit.com/wilzbach/state-of-d/master/report.html
Grep for "What is your tolerance for stability vs. breaking changes". Provided the question is biased, but still, the answers lean heavily in one direction.

But still, people complain. And many core contributors, myself included, will heavily weight against breaking change. So why the apparent disconnect ?
Once again, the person that managed to put it together best was Don Clugston. He mentioned it in his talk @ DConf 2013.

It's exactly 5 minutes, starting from here: https://youtu.be/pmwKRYrfEyY?t=1838

Now, the example that Don used, implicit fallthru, was a win for Sociomantic. But what if there was no bug ? If there was only a handful occurrences, none of them buggy ? Then they would really pay a cost for nothing. A small cost, but a cost nonetheless.

I hit a similar case a few years ago, when I deprecated using the return of the comma operator. To my surprise, there were quite a few users. Even more surprising, after looking at the way this feature was used, it **made perfect sense**. In the particular situations, reading the code, using the return of a comma expression  was... Neat. And here I was, asking those people to change their neat code because I thought it was wrong and led to issues such as `synchronized(a, b)`.

Well turns out, D has one of the most powerful tool to deal with this: "deprecated".
Deprecating something, and giving a decent timeframe, allows to move things forward without destroying the ecosystem. It gives the weary programmer a way to ignore a few annoying deprecations in his/her code when all that programmer's want to do is enjoy the new features in the latest release. It gives times for everyone, including dependency, to tackle the problem, at the minor inconvenience of a little message.

We've been refining deprecated for years. When it started, you could only apply it on functions, and no message was allowed. Then we added support for string literal. Then one day Vibe.d broke because of a stray import to an empty Phobos module, and we added support for deprecated module. Then CTFE-able messages. Along the way, we made sure that one could access deprecated code within a deprecated scope, so a library can keep providing the same functionality to users without breaking compatibility. And with D's amazing feature set, a library can even use `static if (__VERSION__ >= 2094)` to deprecated based on the compiler used.

Did you know that `deprecated` is so amazing that it's the feature that Sociomantic **backported to D1** ? That's right, this feature is so awesome that Sociomantic decided they needed it more than any other D2 features, because of how much it simplified internal libraries updates. And it had amazing ROI.

In conclusion, I simply hope we keep on putting more consideration into why people come to D, as opposed to why people say they won't. And people come to D not for a language that has eternal backwards compatibility, because one simply can use C++ for this.