www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Ghosting a language feature

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
"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.
Sep 20 2020
next sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
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.
Sep 20 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 20 2020
next sibling parent reply Ben Jones <fake fake.fake> writes:
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
Sep 20 2020
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Sep 20 2020
next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
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.
Sep 20 2020
prev sibling next sibling parent reply mw <mingwu gmail.com> writes:
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.
Sep 20 2020
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Sep 20 2020
prev sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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.
Sep 21 2020
prev sibling next sibling parent reply Mathias LANG <geod24 gmail.com> writes:
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.
Sep 21 2020
next sibling parent HaraldZealot <harald_zealot tut.by> writes:
On Monday, 21 September 2020 at 09:06:50 UTC, Mathias LANG wrote:

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

 ...

 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.


I'm 100% agree.
Sep 21 2020
prev sibling next sibling parent Uli <kuettler gmail.com> writes:
On Monday, 21 September 2020 at 09:06:50 UTC, Mathias LANG 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.


 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.


Maybe taking a look at why people are leaving D could be 
instructive, too? Speaking of ghosting.

And think of the unspeakable pleasure of ghosting a Voldemort 
type. Or a callback handler. "Don't call us, we won't call you 
either." The possibilities are endless.
Sep 21 2020
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2020 2:06 AM, Mathias LANG wrote:

 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.


Deprecated is indeed amazing, and it's even sprouting up in other languages!


 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.


My thoughts on this definitely evolve over time.

My current thinking is we should remove a feature if it actively impairs the 
progress and correctness of the language, i.e. if it causes harm. But features 
that are just obsolete, but do not harm things, they can stay as "ghosted" 
features until they do cause harm.

For example, I had some grief with the D2 Phobos because my code was heavily 
dependent on the D1 date and time routines. There was no easy upgrade, and I
did 
not want to spend the time to re-engineer the extensive code. This was the 
genesis of the "undeaD" library, which has turned out to be popular. I 
apparently wasn't the only one.

People may not come to D because it has eternal backwards compatibility, but 
some definitely leave because they got tired of constant breakage.

Personally, I believe C and C++ have gone too far with backwards compatibility, 
as some of that stuff just cripples things going forward.
Sep 21 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 21 September 2020 at 10:39:44 UTC, Walter Bright wrote:


 People may not come to D because it has eternal backwards 
 compatibility, but some definitely leave because they got tired 
 of constant breakage.


Our current release schedule, despite being divided into "major" 
and "patch" releases, is just a string of incremental releases 
every two months. There's nothing to differentiate one major 
release from another -- it's all D2 -- and some may feel pressure 
to update to the latest major compiler release as often as 
possible, risking the headaches of breakage, regressions, and 
with the remedy of only one patch release before it's time to do 
it again.

This situation spawns discussions of D3, std.v2, and now this.

Watching what C++, and especially Java, are doing these days, I 
feel like our approach is antiquated. What we need is an obvious 
way to delineate the feature set of any version of both the 
language and the standard library, and create a path that allows 
for a more leisurely, less risky style of updates.

For example:

* A "milestone" release, say every one or two years, that 
eliminates the 2.x versioning in favor of the year -- D21, D23, 
etc.
* Every release between milestones is a patch release (21.1, 21.2)
* New language and library features are allowed only in milestone 
releases
* Each milestone release is supported with patch releases for a 
fixed number of milestone cycles, and bugfixes that can be 
backported are backported to all supported versions.
* Features can only be deprecated in a milestone release, and are 
removed in a specific milestone release down the road (3 cycles 
or whatever).

With a schedule like this, there's no need for a D3, or a std.v2. 
Ghosting doesn't need to be a thing. We can point specifically to 
the distinct feature sets of D21 and D23 and D25, and Phobos 
21/23/25. I can know that if I choose D21 for my project today, I 
can keep using that specific version of the language, with patch 
release support, until D27 (or whatever) is released. I don't 
have to feel pressure to upgrade to D23, and I can wait until any 
regressions it may have introduced are ironed out before I do 
make the move.

It also allows us to start planning features more coherently (DIP 
10xx has been approved and will be implemented for D25) so that 
the feature set of each milestone release can be mapped out and 
published on the site well before it's released.

My 2 cents.
Sep 21 2020
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
While C++ names things by the year, the compilers don't actually follow this 
schedule. Compilers have varying levels of implementing the new standards, some 
years before, some years after.

Once something is implemented, I don't see the advantage of delaying deployment 
of it, possibly for years, in order to meet some arbitrary milepost.
Sep 21 2020
next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Monday, 21 September 2020 at 23:57:17 UTC, Walter Bright wrote:

 While C++ names things by the year, the compilers don't 
 actually follow this schedule. Compilers have varying levels of 
 implementing the new standards, some years before, some years 
 after.


Doesn't have to be thr year. Java does just fine with sequential 
whole numbers. The point is that I can't tell you which D feature 
came in which release without digging through the changelog, but 
though I don't even use Java anymore I know that switch 
expressions came in Java 12 or 13.



 Once something is implemented, I don't see the advantage of 
 delaying deployment of it, possibly for years, in order to meet 
 some arbitrary milepost.


We have milestone releases already (2.094, 2.095). What we don't 
have is extended patch support or any ckear way to delineate the 
language versions. I mean, D 2.094 is a different languge than D 
2.074. How many people can say how they differ?

And if I want to upgrade from 2.094 to 2.095, but the new version 
introduces a regression that blocks me, that regression might not 
be fixed until 2.098. Now in order to upgrade I need to deal with 
the changes and possible regressions in multiple milestone 
realeases because there's no long-term patch support for 2.095. 
This is not a hypothetical situation. It has happened to 
companies using D in production.
Sep 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2020 6:08 PM, Mike Parker wrote:> D 2.094 is a different languge than D 
2.074. How many people can say how > they differ?
I can't say, either, without looking at the changelog. But does it matter? If a 
particular feature is of interest, can't the changelog suffice?



 And if I want to upgrade from 2.094 to 2.095, but the new version introduces a 
 regression that blocks me, that regression might not be fixed until 2.098. Now 
 in order to upgrade I need to deal with the changes and possible regressions
in 
 multiple milestone realeases because there's no long-term patch support for 
 2.095.


I agree that no long-term patch support is a problem. But it's mainly the
result 
of our team being small, not having a different release scheme. There's nothing 
really preventing a regression fix from going back into any particular release 
except someone actually doing it.

Needing patch support for various versions could be an ideal thing that 
companies that need it can supply funding for.
Sep 21 2020
next sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Tuesday, 22 September 2020 at 04:38:37 UTC, Walter Bright 
wrote:

 On 9/21/2020 6:08 PM, Mike Parker wrote:> D 2.094 is a

 And if I want to upgrade from 2.094 to 2.095, but the new 
 version introduces a regression that blocks me, that 
 regression might not be fixed until 2.098. Now in order to 
 upgrade I need to deal with the changes and possible 
 regressions in multiple milestone realeases because there's no 
 long-term patch support for 2.095.


 I agree that no long-term patch support is a problem. But it's 
 mainly the result of our team being small, not having a 
 different release scheme. There's nothing really preventing a 
 regression fix from going back into any particular release 
 except someone actually doing it.


This sounds like an excuse. There are smaller languages with 
smaller teams that have better backwards compatibility and 
support for it than D does.



 Needing patch support for various versions could be an ideal 
 thing that companies that need it can supply funding for.


How would extra funds help? There's more than one way to solve a 
problem. One such solution would be changing the release scheme.

For example, if a patch needs to be backported for the last 2 
years. You'd have to backport that patch to 12 different versions 
of DMD. If only 2 major releases of DMD were released a year that 
would drop by 66% to 4. Backporting a patch to 4 versions is 
significantly easier and requires less work (and funding :D) to 
actually do.

So the release scheme definitely has an impact. If there's a 
major spec release every 2 years, a patch would only have to be 
backported to 2 versions to support the last 4 years. Where as 
how many versions would you have to backport to to support the 
same amount of time? 20? 30? Who's going to do that? That's a 
waste of time because of the versioning scheme being used.
Sep 22 2020
parent Avrina <avrina12309412342 gmail.com> writes:
On Tuesday, 22 September 2020 at 14:23:51 UTC, Avrina wrote:

 On Tuesday, 22 September 2020 at 04:38:37 UTC, Walter Bright 
 wrote:

 On 9/21/2020 6:08 PM, Mike Parker wrote:> D 2.094 is a

 And if I want to upgrade from 2.094 to 2.095, but the new 
 version introduces a regression that blocks me, that 
 regression might not be fixed until 2.098. Now in order to 
 upgrade I need to deal with the changes and possible 
 regressions in multiple milestone realeases because there's 
 no long-term patch support for 2.095.


 I agree that no long-term patch support is a problem. But it's 
 mainly the result of our team being small, not having a 
 different release scheme. There's nothing really preventing a 
 regression fix from going back into any particular release 
 except someone actually doing it.


 This sounds like an excuse. There are smaller languages with 
 smaller teams that have better backwards compatibility and 
 support for it than D does.



 Needing patch support for various versions could be an ideal 
 thing that companies that need it can supply funding for.


 How would extra funds help? There's more than one way to solve 
 a problem. One such solution would be changing the release 
 scheme.

 For example, if a patch needs to be backported for the last 2 
 years. You'd have to backport that patch to 12 different 
 versions of DMD. If only 2 major releases of DMD were released 
 a year that would drop by 66% to 4. Backporting a patch to 4 
 versions is significantly easier and requires less work (and 
 funding :D) to actually do.

 So the release scheme definitely has an impact. If there's a 
 major spec release every 2 years, a patch would only have to be 
 backported to 2 versions to support the last 4 years. Where as 
 how many versions would you have to backport to to support the 
 same amount of time? 20? 30? Who's going to do that? That's a 
 waste of time because of the versioning scheme being used.


To add on to that, every version a patch is backported to has 
potential to cause it's own bugs and regressions. So if you have 
20 or more versions you'd have to support for a period of 4 
years, that's just not feasible, regardless of manpower or 
funding.
Sep 22 2020
prev sibling parent reply Don <prosthetictelevisions teletubby.medical.com> writes:
On Tuesday, 22 September 2020 at 04:38:37 UTC, Walter Bright 
wrote:

 On 9/21/2020 6:08 PM, Mike Parker wrote:> D 2.094 is a 
 different languge than D 2.074. How many people can say how > 
 they differ?
 I can't say, either, without looking at the changelog. But does 
 it matter? If a particular feature is of interest, can't the 
 changelog suffice?



 And if I want to upgrade from 2.094 to 2.095, but the new 
 version introduces a regression that blocks me, that 
 regression might not be fixed until 2.098. Now in order to 
 upgrade I need to deal with the changes and possible 
 regressions in multiple milestone realeases because there's no 
 long-term patch support for 2.095.


 I agree that no long-term patch support is a problem. But it's 
 mainly the result of our team being small, not having a 
 different release scheme. There's nothing really preventing a 
 regression fix from going back into any particular release 
 except someone actually doing it.

 Needing patch support for various versions could be an ideal 
 thing that companies that need it can supply funding for.


Delurking because this is a really important issue.

Unfortunately that doesn't really work. You need to have 
designated long-term support releases. There doesn't need to be 
very many of them, but they must exist.
Currently the most recent one is called D1. :)

What I think most of the community doesn't realize with this 
issue, is that just because a body of code needs compiler 
patches, does *not* mean that any development is happening. I 
didn't appreciate this until it happened to me.

Here's what happened in the dying days of Sociomantic. All 
development ceased on the project. But, the apps still needed to 
run, until our contracts with existing customers ran out.

But then the Linux version we were running on, ran out of 
support. We had to upgrade the servers to a supported Linux 
version. But we could not do this. All supported Linux versions 
required position independent code.
Simple, just add -fPIC to the Makefile, and recompile.

I wish.

Unfortunately there was a wrong-code bug in the compiler, which 
happened if compiled with -fPIC. This was only fixed in the most 
recent compiler release.
So, we have to jump forward many releases. And these releases 
included some huge deprecations. When I did this, the compiler 
spat out over 3000 errors. In many of these cases the required 
changes were far from trivial. Most of the team has left by that 
point, so I have to make the changes and hope I didn't break 
something in the process.

Then, after making all these changes, I discover there's been a 
regression before the -fPIC fix. The regression is fixed since 
the last release. So the only compiler that works is the nightly 
build of dmd. This is so unprofessional it blows my mind.

Remember, all the budget allowed for was, add -fPIC and recompile.

Back in 2007, D had a long-term support release. It needs a more 
recent one.
That's not a luxury, it's a necessity. You're not a serious 
language without one.
Just *one* LTS at any given time would be a good start.
Sep 25 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Friday, 25 September 2020 at 15:49:54 UTC, Don wrote:

 Back in 2007, D had a long-term support release. It needs a 
 more recent one.
 That's not a luxury, it's a necessity. You're not a serious 
 language without one.
 Just *one* LTS at any given time would be a good start.


Nice to see someone agree with a position I've always had. I like 
that Debian has a stable release that is very conservative.

For a server-compiler it might be a good idea to backport to 
whatever version of the compiler is the "default" at the Debian 
stable release.
Sep 25 2020
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/25/2020 8:49 AM, Don wrote:

 Unfortunately there was a wrong-code bug in the compiler, which happened if 
 compiled with -fPIC. This was only fixed in the most recent compiler release.
 So, we have to jump forward many releases. And these releases included some
huge 
 deprecations. When I did this, the compiler spat out over 3000 errors. In many 
 of these cases the required changes were far from trivial. Most of the team
has 
 left by that point, so I have to make the changes and hope I didn't break 
 something in the process.
 
 Then, after making all these changes, I discover there's been a regression 
 before the -fPIC fix. The regression is fixed since the last release. So the 
 only compiler that works is the nightly build of dmd. This is so
unprofessional 
 it blows my mind.
 
 Remember, all the budget allowed for was, add -fPIC and recompile.
 
 Back in 2007, D had a long-term support release. It needs a more recent one.
 That's not a luxury, it's a necessity. You're not a serious language without
one.
 Just *one* LTS at any given time would be a good start.


This is the first time I've heard of your travails on this.

I'm sorry this burden fell on you. You needed two patches to an older compiler. 
There's only one way this can happen - someone has to apply those patches to
the 
older compiler, and test the result.

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.

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.

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.
Oct 01 2020
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Thursday, 1 October 2020 at 09:49:20 UTC, Walter Bright wrote:

 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.


Clearly not. There are at least two options:

1. Do as C++ compilers do, support multiple language-versions to 
the same backend. The easiest way to do this is to have a shared 
mid-level IR and ship with multiple front ends.

2. Label a specific Linux distribution as supported and specific 
compiler front ends, and make sure that all those work on the 
last few major releases of that Linux distribution.

Then plan for it. It is a matter of strategic choices. Not at all 
difficult to achieve. (Just refuse changes that jeopardise the 
core strategy.)
Oct 01 2020
prev sibling parent Jackel <jackel gmx.com> writes:
Who decides now?

The people deciding now have no recourse, if an LTS version 
existed, they would have.

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. ""
Oct 06 2020
prev sibling parent reply Avrina <avrina12309412342 gmail.com> writes:
On Monday, 21 September 2020 at 23:57:17 UTC, Walter Bright wrote:

 Once something is implemented, I don't see the advantage of 
 delaying deployment of it, possibly for years, in order to meet 
 some arbitrary milepost.


A lot of c++ features get implemented before the spec is 
finalized. You can use the features by specifying a specific 
version. For anyone that wants bleeding edge they can access the 
new features. Those new features tend to introduce regressions 
and are buggy. The bugs that get ironed out early on don't follow 
deprecation paths as the feature is still new and isn't used that 
wildly, so breaking changes are let through more easily in these 
cases. Discouraging investing in using the feature even if it is 
"implemented".
Sep 21 2020
parent reply Avrina <avrina12309412342 gmail.com> writes:
On Tuesday, 22 September 2020 at 03:19:43 UTC, Avrina wrote:

 On Monday, 21 September 2020 at 23:57:17 UTC, Walter Bright 
 wrote:

 Once something is implemented, I don't see the advantage of 
 delaying deployment of it, possibly for years, in order to 
 meet some arbitrary milepost.


 A lot of c++ features get implemented before the spec is 
 finalized. You can use the features by specifying a specific 
 version. For anyone that wants bleeding edge they can access 
 the new features. Those new features tend to introduce 
 regressions and are buggy. The bugs that get ironed out early 
 on don't follow deprecation paths as the feature is still new 
 and isn't used that wildly, so breaking changes are let through 
 more easily in these cases. Discouraging investing in using the 
 feature even if it is "implemented".


That's to say if you want how D is developed now you'd just use 
-spec=d2.xy and it'll enable be at the bleeding edge. What'd this 
introduce is a way for people that want and need backwards 
co.patibility to have it.
Sep 21 2020
parent reply Mathias LANG <geod24 gmail.com> writes:
On Tuesday, 22 September 2020 at 03:24:32 UTC, Avrina wrote:

 That's to say if you want how D is developed now you'd just use 
 -spec=d2.xy and it'll enable be at the bleeding edge. What'd 
 this introduce is a way for people that want and need backwards 
 co.patibility to have it.


We have `-preview` for this.
Sep 21 2020
parent Avrina <avrina12309412342 gmail.com> writes:
On Tuesday, 22 September 2020 at 03:49:22 UTC, Mathias LANG wrote:

 On Tuesday, 22 September 2020 at 03:24:32 UTC, Avrina wrote:

 That's to say if you want how D is developed now you'd just 
 use -spec=d2.xy and it'll enable be at the bleeding edge. 
 What'd this introduce is a way for people that want and need 
 backwards co.patibility to have it.


 We have `-preview` for this.


Doesn't solve the problems Mike outlined. I've experienced the 
same problems, a regression preventing me from using using a new 
version of DMD, while the new version has a bug fix I needed.
Sep 22 2020
prev sibling parent James Blachly <james.blachly gmail.com> writes:
On 9/21/20 7:15 AM, Mike Parker wrote:

 Our current release schedule, despite being divided into "major" and 
 "patch" releases, is just a string of incremental releases every two 
 months. There's nothing to differentiate one major release from another 
 -- it's all D2 -- and some may feel pressure to update to the latest 
 major compiler release as often as possible, risking the headaches of 
 breakage, regressions, and with the remedy of only one patch release 
 before it's time to do it again.
 
 This situation spawns discussions of D3, std.v2, and now this.
 
 Watching what C++, and especially Java, are doing these days, I feel 
 like our approach is antiquated. What we need is an obvious way to 
 delineate the feature set of any version of both the language and the 
 standard library, and create a path that allows for a more leisurely, 
 less risky style of updates.
 


...


 My 2 cents.


All excellent comments. It is worth bringing up Rust here, which also 
uses year-edition as a demarcation point, but does so slightly 
differently than C++.

Interestingly, new features are delivered continuously (much as we do 
with D), until such time that a new "edition" is frozen such that the 
feature set at that time is designated "2018" (or whatever) and is a 
well-defined point-in-time that you may use safely in the future. If you 
want new features, you can use them but you must use stable, beta, or 
nightly.

https://doc.rust-lang.org/book/appendix-05-editions.html
https://doc.rust-lang.org/book/appendix-07-nightly-rust.html

I could see "D 2021 edition" :)
Sep 21 2020
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 21 September 2020 at 10:39:44 UTC, Walter Bright wrote:

 Personally, I believe C and C++ have gone too far with 
 backwards compatibility, as some of that stuff just cripples 
 things going forward.


Hoho, that not even the worst part. You have dinosaur programmers 
keep programming in c++98 edition irregardless of the current c++ 
version. I remember cpp experts begging people to program c++ in 
a modern way,  but nope. You have college professor/programmer 
dinosaurs teach/program in c++98.


Regardless "legacy feature" is the right way to go, as the name 
implies it is legacy. Give it compilers warnings indicating that 
you not suppose to write new code with it.

If I were you I would mark alias this as a legacy feature, and 
introduce an dip that introduce implicit conversions in a very 
restrictive matter so that it could be replace properly.(Or we 
could think outside the box and introduce extended constructors, 
to replace the need for implicit conversions)

-Alex
Sep 21 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 21 September 2020 at 13:32:16 UTC, 12345swordy wrote:

 If I were you I would mark alias this as a legacy feature, and 
 introduce an dip that introduce implicit conversions in a very 
 restrictive matter so that it could be replace properly.(Or we 
 could think outside the box and introduce extended 
 constructors, to replace the need for implicit conversions)


My guess is that allowing a struct to inherit from another struct 
would cover around 80% of the use-cases for `alias this`. So 
instead of writing

     struct Wrapper(T) {
         T payload;
         alias payload this;
         // etc.
     }

...you could just write:

     struct Wrapper(T) : T {
         // etc.
     }

For other cases where people want implicit conversions, we can 
either add something like implicit constructors/opCast overloads, 
or just tell them to use explicit conversions instead.
Sep 21 2020
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 9/21/2020 7:08 AM, Paul Backus wrote:

 My guess is that allowing a struct to inherit from another struct would cover 
 around 80% of the use-cases for `alias this`.


The use case not covered by it is forwarding to a function.
Sep 21 2020
parent reply Paul Backus <snarwin gmail.com> writes:
On Monday, 21 September 2020 at 20:49:00 UTC, Walter Bright wrote:

 On 9/21/2020 7:08 AM, Paul Backus wrote:

 My guess is that allowing a struct to inherit from another 
 struct would cover around 80% of the use-cases for `alias 
 this`.


 The use case not covered by it is forwarding to a function.


Since I didn't have a clear idea of how common this was, I 
decided to do a quick grep through Phobos to see how many `alias 
this` declarations forwarded to a member variable vs. a function. 
Excluding unit-test code, my results were:

Variable: 15
Function: 14

So, pretty much exactly 50/50--my guess was totally off.
Sep 21 2020
parent Walter Bright <newshound2 digitalmars.com> writes:
I had the same idea as you did, and ran aground for the same reason.
Sep 21 2020
prev sibling parent JN <666total wp.pl> writes:
On Monday, 21 September 2020 at 09:06:50 UTC, Mathias LANG wrote:

 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.


I think a big source of problems when introducing breaking 
changes was that it wasn't really tested on any prominent 
codebases, so the only breakage index was D unit tests. As far as 
I know, DMD is tested against top N dub packages at the moment, 
so before you break something for users you can figure out how 
much of an effort it will be. There is a difference between 
breaking top packages and breaking a single package that only few 
people use.
Sep 22 2020
prev sibling parent Avrina <avrina12309412342 gmail.com> writes:
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.


Dropping support for the feature is just as irritating, even if 
the feature is still present. You might as well be removing it. 
You are still forcing the user to not use the feature one way or 
another.

What Mike proposes is a better alternative.
Sep 21 2020
prev sibling next sibling parent DlangUser38 <DlangUser38 nowhere.se> writes:
On Monday, 21 September 2020 at 01:09:09 UTC, Andrei Alexandrescu 
wrote:

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


"Ghosting", "Laugh test", that's really sad. Are you under the 
influence of toxic people since recently ?
Sep 21 2020
prev sibling next sibling parent matheus <matheus gmail.com> writes:
On Monday, 21 September 2020 at 01:09:09 UTC, Andrei Alexandrescu 
wrote:

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


So if some poor programmer stumble in a legacy code and need to 
read the doc, he will be punished with a unpleasant styling, 
small fonts, gray text?

I really don't understand this.

Matheus.
Sep 21 2020
prev sibling parent Jackel <jackel gmx.com> writes:
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.
Oct 06 2020