Ghosting a language feature

[Jackel]

On Thursday, 1 October 2020 at 09:49:20 UTC, WB wrote:
> Having a LTS version does literally nothing to make this 
> happen. To make this work, an engineer has to be available to 
> make it work, someone that can "add patch X to release Y". The 
> only way that can happen is for someone to volunteer to do it, 
> or for someone to be paid to do it.

When a pull request is made, it would be trivial to require a 
patch to also be made to a LTS version of the compiler.

> Another problem is there are what, 20,000 PRs for dmd? Which 
> ones need to be put in the LTS version? Who decides? The only 
> workable scheme I can think of is the customer who needs X 
> (every customer has different issues that need attention) needs 
> to find or fund an engineer to do it. This is why D is open 
> source.

Who decides now?

The people deciding now have no recourse, the current `-preview=` 
implementation only works if the before and after code can 
co-exist. Which in a lot of cases it can't. Not to mention 
there's no `-preview=` switch for breaking changes done to 
phobos. It's an ineffective tool for the problem.

See here: 
https://github.com/dlang/dmd/pull/9289#issuecomment-468633169

     "" It seems that the projects listed in buildkite don't 
suffer from this bug so I suggest we just swallow this pill and 
merge this. ""

Had an LTS version, or some sort of spec versioning scheme been 
used, this situation could have allowed the people deciding to 
only apply this patch to be applied to the new spec or not the 
LTS version of the compiler.

Of course it ended up causing problems: 
https://forum.dlang.org/post/zzgbrxtehffhjkcazpzs@forum.dlang.org

Every company and/or customer requires LTS. It is ubiquitous. 
There's no customer Y needs X, that's just a symptom of a larger 
problem. Customer Y needs X cause there's no LTS.

> All I can helpfully suggest is we (the topic of this thread) 
> avoid removing harmless features just because they are 
> obsolete. This will reduce (hopefully eliminate) the redesigns 
> necessary to move forward.

I think this will only exacerbate the problem, if you mean to 
suggest to follow through with "ghosting" features. If what is 
said to be taken at face value, since all bug reports for that 
feature will be closed as "won't fix". Should a regression occur 
to a ghosted feature, it won't ever be fixed. So even if a 
"ghosted" feature remains it will still cause problems for 
someone trying to upgrade to a newer version of the compiler. A 
ghosted feature can't remain without support for it, otherwise it 
might as well be removed.