There have been a lot of this pattern happening:

1. We need to add feature X, to fix problem Y.
2. This will break ALL CODE IN EXISTENCE
3. OK, cancel the fix, we'll just live with it.

Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.

Some issues I can think of:

1. The safe by default debate
2. pure by default
3. nothrow by default
4. String interpolation DIP
5. auto-decoding
6. range.save
7. virtual by default
8. ProtoObject

Other languages evolve much quicker than D, but break things only in major updates. D seems to "sort of" break things, there's always a risk in every release. We try to be conservative, but we have this horrible mix of deciding some features can break things, while others are not allowed to, and there's no clear guide as to which breakage fits in which category.

If we went to a more regular major release schedule, and decided for a roadmap for each major release what features would be included, it would allow much better planning, and much more defensible breakage of code. If you know that your code will only compile with D2.x, and you're fine with that, then great, don't upgrade to D3.x. If you desperately want a feature, you may have to upgrade to D3.x, but once you get there, you know your code is going to build for a while.

We could also not plan for many major releases, but at least move to D3 for some major TLC to the language that is held back to prevent breakage.

I work occasionally with Swift, and they move very fast, and break a lot of stuff, but only in major versions. It's a bit fast for my taste, but it seems to work for them. And they get to fix issues that languages like C++ might have been stuck with forever.

The biggest drawback is that we aren't a huge language, with lots of manpower to keep x branches going at once.

I just wanted to throw it out as a discussion point. We spend an awful lot of newsgroup server bytes debating things that to me seem obvious, but have legitimate downsides for not breaking them in a "stable" language.

-Steve

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> [...]

Didn't the 1.0 to 2.0 conversion nearly kill the language?

-Alex

On 3/27/20 12:03 PM, 12345swordy wrote:
> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>> There have been a lot of this pattern happening:
>>
>> 1. We need to add feature X, to fix problem Y.
>> 2. This will break ALL CODE IN EXISTENCE
>> 3. OK, cancel the fix, we'll just live with it.
>>
>> [...]
> 
> Didn't the 1.0 to 2.0 conversion nearly kill the language?

No.

-Steve

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>
> 1. We need to add feature X, to fix problem Y.
> 2. This will break ALL CODE IN EXISTENCE
> 3. OK, cancel the fix, we'll just live with it.
>
> Having a new branch of the compiler will provide a way to keep D2 development alive while giving a playground to add new mechanisms, fix long-existing design issues, and provide an opt-in for code breakage.
>
> Some issues I can think of:
>
> 1. The safe by default debate
> 2. pure by default
> 3. nothrow by default
> 4. String interpolation DIP
> 5. auto-decoding
> 6. range.save
> 7. virtual by default
> 8. ProtoObject
>
> Other languages evolve much quicker than D, but break things only in major updates. D seems to "sort of" break things, there's always a risk in every release. We try to be conservative, but we have this horrible mix of deciding some features can break things, while others are not allowed to, and there's no clear guide as to which breakage fits in which category.
>
> If we went to a more regular major release schedule, and decided for a roadmap for each major release what features would be included, it would allow much better planning, and much more defensible breakage of code. If you know that your code will only compile with D2.x, and you're fine with that, then great, don't upgrade to D3.x. If you desperately want a feature, you may have to upgrade to D3.x, but once you get there, you know your code is going to build for a while.
>
> We could also not plan for many major releases, but at least move to D3 for some major TLC to the language that is held back to prevent breakage.
>
> I work occasionally with Swift, and they move very fast, and break a lot of stuff, but only in major versions. It's a bit fast for my taste, but it seems to work for them. And they get to fix issues that languages like C++ might have been stuck with forever.
>
> The biggest drawback is that we aren't a huge language, with lots of manpower to keep x branches going at once.
>
> I just wanted to throw it out as a discussion point. We spend an awful lot of newsgroup server bytes debating things that to me seem obvious, but have legitimate downsides for not breaking them in a "stable" language.
>
> -Steve

D has been around for 20 years and hasn't gained the traction that younger languages like Rust or Go have (though as we all know, the main reason for this is D's lack of a big corporate patron a la Mozilla or Google). Maybe what's needed is a "new" language that breaks backwards compatibility (as conservatively as possible and hopefully in a way that makes it easy to automatically port your D2 code).

Walter originally wanted to call it the Mars language - maybe it's time to revive that name in a complete rebranding of the language.

On Friday, 27 March 2020 at 16:54:28 UTC, Steven Schveighoffer wrote:
> On 3/27/20 12:03 PM, 12345swordy wrote:
>> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>>> There have been a lot of this pattern happening:
>>>
>>> 1. We need to add feature X, to fix problem Y.
>>> 2. This will break ALL CODE IN EXISTENCE
>>> 3. OK, cancel the fix, we'll just live with it.
>>>
>>> [...]
>> 
>> Didn't the 1.0 to 2.0 conversion nearly kill the language?
>
> No.
>
> -Steve

Oh, must had conflict it with something else.

This article is still relevant to this day.

https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
> There have been a lot of this pattern happening:
>

> 7. virtual by default

You mean final, by default, right?

On 3/27/20 12:58 PM, 12345swordy wrote:
> On Friday, 27 March 2020 at 16:54:28 UTC, Steven Schveighoffer wrote:
>> On 3/27/20 12:03 PM, 12345swordy wrote:
>>> Didn't the 1.0 to 2.0 conversion nearly kill the language?
>>
>> No.
>>
> 
> Oh, must had conflict it with something else.

There was an issue with an alternative standard library (Tango), which divided the community. That shouldn't be a problem for a D3.

-Steve

On 3/27/20 12:59 PM, Paolo Invernizzi wrote:
> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>> There have been a lot of this pattern happening:
>>
> 
>> 7. virtual by default
> 
> You mean final, by default, right?

Yes, I meant the issue that virtual is the default but it shouldn't be. At one point, we had merged in a change for this, and it was reverted.

-Steve

On Fri, 2020-03-27 at 16:55 +0000, Meta via Digitalmars-d wrote:
> 
[…]
> D has been around for 20 years and hasn't gained the traction that younger languages like Rust or Go have (though as we all know, the main reason for this is D's lack of a big corporate patron a la Mozilla or Google). Maybe what's needed is a "new" language that breaks backwards compatibility (as conservatively as possible and hopefully in a way that makes it easy to automatically port your D2 code).

Whilst D has not had the hype or the instant traction of Rust and Go, it does have some traction and mindshare. This is based on it's history, and it would (in my opinion) be a bad idea to lose this.

I think having a positive strategy towards a D v3 would be a good idea but only if there are big breaking changes to D v2. The current Java evolution strategy is fine, but it's version numbering is an unimitigated disaster – in my view. Groovy has though had the right evolution strategy and the right approach to version numbering – it has fairly recently released v3 for all exactly the right reasons.

> Walter originally wanted to call it the Mars language - maybe it's time to revive that name in a complete rebranding of the language.

I think having a brand new language that just happened to have a very simple upgrade path from D v2 would be a self-defeating activity. People would very quickly spot the con.

If D has a future it is in terms of v3, v4, etc. with a strong
technical evolution (cf. Groovy) and good marketing. Clearly D
remaining at v2 for ever more would, I feel,  be a Very Bad Idea™ since
it advertises no changes to the language, i.e. a language with a
stalled evolution.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Friday, 27 March 2020 at 16:58:03 UTC, 12345swordy wrote:
> On Friday, 27 March 2020 at 16:54:28 UTC, Steven Schveighoffer wrote:
>> On 3/27/20 12:03 PM, 12345swordy wrote:
>>> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>>>> There have been a lot of this pattern happening:
>>>>
>>>> 1. We need to add feature X, to fix problem Y.
>>>> 2. This will break ALL CODE IN EXISTENCE
>>>> 3. OK, cancel the fix, we'll just live with it.
>>>>
>>>> [...]
>>> 
>>> Didn't the 1.0 to 2.0 conversion nearly kill the language?
>>
>> No.
>>
>> -Steve
>
> Oh, must had conflict it with something else.
>
> This article is still relevant to this day.
>
> https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/


Thanks For the article you reference the URL. Now I know throwing away your codebase is not the right decision. Proper refactoring and improvement is the way to go. A am a little wiser now.