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.

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.

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.

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 ?

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.

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

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.

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.

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.

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.