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

I think in any case something is required, not sure if D 3.0 would be it though, D is already known for having had too many unfinished features, even if the reality isn't as bad as those people portray it.

For me personally, I don't care that much about D's metaprogramming capabilities, so D lost me when C# 7 started adding features taken from Midori project for low level programming, and when GraalVM graduated from Oracle Research labs.

Java and .NET have OS vendors backing, distributed computing, game industry support, big data, to sell as "why use X".

Swift, Objective-C have Apple's mighty hand to sell as "why use X".

Rust has the message of "security above anything else" and now has Apple, Microsoft, Google on boat as well, doing OS features in Rust. All of them are hiring Rust developers currently.

Even though those are the same companies that are heavily invested in C++ eco-system, and keep doing strong investments into ISO C++, compilers and IDE tooling.

NVidia, a strong C++ house is now using Ada as well, for high integrity firmware development.

So D 3.0 or not, what D needs is to finally get is act together about what story the community wants to sell.

If this doesn't happen, I have the feeling that D will eventually die when the core team for whatever reason decides to focus elsewhere.

--
Paulo

On Saturday, 28 March 2020 at 05:19:52 UTC, rikki cattermole wrote:
> On 28/03/2020 5:41 PM, Jesse Phillips wrote:
>> On Friday, 27 March 2020 at 15:56:40 UTC, Steven Schveighoffer wrote:
>>> [...]
>> 
>> 
>> Yes, but not because we want to break things, but because we are breaking things.
>> 
>> The preview switches are great, but can we get a grouped feature set for release.
>> 
>> It is critical that the existing libraries can be utilized with newer language versions (at least for a time).
>> 
>> Stationary is not an option, but a good upgrade which does not compromise the ecosystem is vital.
>
> I have said this before, D3 should be a preview switch which turns on all the others.
>
> All D2 code should be compilable with D3, but not all D3 should be compilable as D2.
>
> dmd3 could literally be the preview switch turned on permanently.



This is a possible path to go through. The D community must be bold to move forward. There seems to be much time mow, it is time to map a clear road path for D.

On 3/27/2020 10:22 AM, Russel Winder wrote:
> 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.

If this happens it still seems like a marketing failure. After all, C++ gets a year appended and yet has large changes.

On Friday, 27 March 2020 at 17:22:30 UTC, Russel Winder wrote:
> 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.

Groovy isn't properly a good exemple.

If it wasn't for Gradle and its use in Android, it would be long gone and forgotten.

And even there, there is a big pressure to replace it with Kotlin, in what regards Android build infrastructure.

So is the fate of any guest language until the main platform language catches up.

--
Paulo

On Saturday, 28 March 2020 at 05:19:52 UTC, rikki cattermole wrote:
> On 28/03/2020 5:41 PM, Jesse Phillips 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.
>> 
>> 
>> Yes, but not because we want to break things, but because we are breaking things.
>> 
>> The preview switches are great, but can we get a grouped feature set for release.
>> 
>> It is critical that the existing libraries can be utilized with newer language versions (at least for a time).
>> 
>> Stationary is not an option, but a good upgrade which does not compromise the ecosystem is vital.
>
> I have said this before, D3 should be a preview switch which turns on all the others.
>
> All D2 code should be compilable with D3, but not all D3 should be compilable as D2.
>
> dmd3 could literally be the preview switch turned on permanently.

I like this idea. It's simple and pragmatic. The documentation could recommend this to new users, who don't yet know what the right defaults should be, and everyone else could do the transition when they feel like it. At some point in the future it could be the default and the we could bump the version to D3.

On Saturday, 28 March 2020 at 05:19:52 UTC, rikki cattermole wrote:
> I have said this before, D3 should be a preview switch which turns on all the others.
>
> All D2 code should be compilable with D3, but not all D3 should be compilable as D2.
>
> dmd3 could literally be the preview switch turned on permanently.

Yes. I think the can compile causes some changes inaccessible, but I think it is necessary to keep things moving.

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:

I have long wanted to offer but there was no suitable place. I would like to propose to trivial rename standart type names by this way:

int -> int32
ulong -> uint64
float -> float32
double -> float64
byte -> octet

Reason:

Most developers no longer remember where these names came from and why it are so called. In the future this number will close to 100%. And soon we will have access to all sorts of non-standard FPGA implemented CPUs with a different byte size, for example.

(It will also break existing code very reliably and it will be difficult to confuse up code of different Dlang versions.)

On Saturday, 28 March 2020 at 17:09:34 UTC, Denis Feklushkin wrote:
>
> int -> int32
> ulong -> uint64
> float -> float32
> double -> float64
> byte -> octet
>

In this case wouldn't it be better to rename them to shorter u8, i8 .. u64, i64 and f32 .. f64. This is actually not a breaking change and we can implement it today if we want to with the old type names still there. Also, you can make whatever alias you want.

On Saturday, 28 March 2020 at 17:09:34 UTC, Denis Feklushkin 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.
>>
>> 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:
>
> I have long wanted to offer but there was no suitable place. I would like to propose to trivial rename standart type names by this way:
>
> int -> int32
> ulong -> uint64
> float -> float32
> double -> float64
> byte -> octet

You could make an argument for the other ones, but I'm pretty sure
everyone understands what is meant by 'byte' 99% of the time.

On Saturday, 28 March 2020 at 17:29:57 UTC, Les De Ridder wrote:

>> byte -> octet
>
> You could make an argument for the other ones, but I'm pretty sure
> everyone understands what is meant by 'byte' 99% of the time.

At this decade.

I specifically wrote remark about FPGA. Creating new processors becomes easy as creating software for them.

In the future we will have a lot of different processors inside of PC case. I can easily imagine special purpose CPU with byte sized 6 or 16. So as for me it’s better to get rid of this name, since in the very first version of D language it was declared that standard types are platform independent (except size_t of course).