D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be.

There have been many changes suggested over time to improve the language, but they were rejected as they would inevitably cause breaking changes.  I think that breaking changes are something to be careful about, and they can definitely be a nuisance to adapt to.  But they must happen once in a while for things to advance.

I think it's about time for D3 to start developing.  So many suggestions for language changes have accumulated by now so I think that it's time to introduce to introduce the next wave of breaking changes.
It's nice to see that there's a wiki page that documents the history of suggested language changes. I applaud the organization.
https://wiki.dlang.org/Language_design_discussions

I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just continue using D2 as they are. Even after D3 is stabilized, D2 could have continued support until nobody wants it.

In Lua (a language with a bigger past and hopefully smaller future than D), breaking changes are introduced in even minor versions.  While I do think that's excessively frequent, there are still users of Lua 5.1.  Making D3 doesn't mean that D2 has to die.

I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2.

Here are some ways that D3 can be an improvement of D2:
-Final by default
-A standard library that is effective with or without garbage collection

Even Andrei has admitted some issues with D when answering this Quora question:
https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why

Even if you don't want to release a D3 too soon, I think it definately makes sense to get started sooner rather than later.  D3 should be developed for the same reason that D was first developed; to make a better programming language that learns from the problems of the one before.

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
> D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be.
>
> [...]

FYI: There also has been a recent debate about developing a new version of Phobos (http://forum.dlang.org/post/volmdaxjihbkpbtplynj@forum.dlang.org) to be able to get rid of auto-decoding, make everything work nicely with @nogc and allocators, fix design issues with ranges, cleanup messy packages (e.g. std.traits), etc.

I think everyone on the forums here agrees about the problems, it's just not clear what the best course of action is as breaking changes are costly. Remember that there are still companies using D1 or Python 2 out there.
OTOH many people representing companies have already vouched here that they would love to see the annoyances fixed and something these issues are even blockers for their official D use at work ...

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:

I'd be fascinated by a revised D like language, say D3 or whatever.

> Here are some ways that D3 can be an improvement of D2:
> -Final by default

Wow, after all that, this is it? I think final by default would be an improvement, and I wish it had gone through, but it's not a big enough deal to make a new language.

> -A standard library that is effective with or without garbage collection

That's being worked on with D right now, isn't it?

If you're not going to be very bold, what's the point of a D3? Let's really change stuff!

> Structs, enums, and pattern matching, like Rust and ML
> Type follows name like Ada, Scala, Rust, ...
> Macros like Nim
> Parallel features from Chapel

I think it's a huge uphill battle for a new language these days, and that there's more to be gained from fixing the current D and others, but I encourage you to design the next D.

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
> D is a language with much promise, but it still has many problems that prevent it from being the great replacement for C++ that it was always meant to be.
>
> There have been many changes suggested over time to improve the language, but they were rejected as they would inevitably cause breaking changes.  I think that breaking changes are something to be careful about, and they can definitely be a nuisance to adapt to.  But they must happen once in a while for things to advance.
>
> I think it's about time for D3 to start developing.  So many suggestions for language changes have accumulated by now so I think that it's time to introduce to introduce the next wave of breaking changes.
> It's nice to see that there's a wiki page that documents the history of suggested language changes. I applaud the organization.
> https://wiki.dlang.org/Language_design_discussions
>
> I realize that there are people who want to continue using D as it is, but those people may continue to use D2. Putting the breaking changes in a separate branch ensures that DM won't lose current clients as they can just continue using D2 as they are. Even after D3 is stabilized, D2 could have continued support until nobody wants it.
>
> In Lua (a language with a bigger past and hopefully smaller future than D), breaking changes are introduced in even minor versions.  While I do think that's excessively frequent, there are still users of Lua 5.1.  Making D3 doesn't mean that D2 has to die.
>
> I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2.
>
> Here are some ways that D3 can be an improvement of D2:
> -Final by default
> -A standard library that is effective with or without garbage collection
>
> Even Andrei has admitted some issues with D when answering this Quora question:
> https://www.quora.com/Which-language-has-the-brightest-future-in-replacement-of-C-between-D-Go-and-Rust-And-Why
>
> Even if you don't want to release a D3 too soon, I think it definately makes sense to get started sooner rather than later.
>  D3 should be developed for the same reason that D was first developed; to make a better programming language that learns from the problems of the one before.

Dev resources are stretched thin as it is, I doubt the core team would go for it.  For example, the vast majority of the work on the main compiler frontend in the last year was done by one person, 3-5 if you're being generous:

https://github.com/dlang/dmd/graphs/contributors?from=2016-05-01&to=2017-06-10&type=c

I think we need to build that team up before we consider branching again.  While it has now been longer since the D2 branch than from the beginning to D2, I get the impression the core team is nowhere near finished with D2, to the point where they want to branch again.

While I personally think a D3 branch now would make sense on the technical merits, I doubt we're at an organizational state where we can afford it, ie not enough manpower.

On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
> Dev resources are stretched thin as it is, I doubt the core team would go for it.

I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.

Liam McGillivray wrote:

> I feel like D3 would see significantly wider adoption than D2 ever got, as long as it successfully solves the problems of D2.

..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-) is trying to cut all the features that aren't strictly necessary (including fat-free stdlib too: i see stdlib as a part of the language).

Adam D. Ruppe wrote:

> On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
>> Dev resources are stretched thin as it is, I doubt the core team would go for it.
>
> I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.

actually, some time ago i proposed to create "experimental and breaking language changes" subforum, where people can go with their wild ideas, and other people can post patches/builds with those (or other) ideas imlemented/half-implemented.

this way we can gather some feedback from someone who is really using new feature, and have a better vision if it worth further time investments or not. 'cause having a live compiler with new feature to play with is not the same as simply dicussing the possible feature in NG. i maintain my private fork of dmd/druntime/phobos, and this is the way i evaluate features: just add what i can, and then see if i'll start using it in my code. if not, the feature is cutted, otherwise it is retained.

and ah, building dmd from sources is not something many people want/can to do. sure, downloading binaries from random people over the net is not the safest thing to do, but if there will be patch+binary combos, it may work.

i.e. i see that "experimental" subforum as a place for ideas *and* implementations. and implementors can provide built binaries for people to play, or other people can build binaries ('cause if you built it for yourself, why don't share it with others?).

i know that this forum is actually a newsgroup, and it can't host files. but i believe that this problem can be solved -- either by using some simple js-free (for download; yeah, there are such things! ;-) service to host binaries, or by some other means.

On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:
> Adam D. Ruppe wrote:
>
>> On Sunday, 11 June 2017 at 00:06:13 UTC, Joakim wrote:
>>> Dev resources are stretched thin as it is, I doubt the core team would go for it.
>>
>> I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.
>
> actually, some time ago i proposed to create "experimental and breaking language changes" subforum, where people can go with their wild ideas, and other people can post patches/builds with those (or other) ideas imlemented/half-implemented.
>
> this way we can gather some feedback from someone who is really using new feature, and have a better vision if it worth further time investments or not. 'cause having a live compiler with new feature to play with is not the same as simply dicussing the possible feature in NG. i maintain my private fork of dmd/druntime/phobos, and this is the way i evaluate features: just add what i can, and then see if i'll start using it in my code. if not, the feature is cutted, otherwise it is retained.
>
> and ah, building dmd from sources is not something many people want/can to do. sure, downloading binaries from random people over the net is not the safest thing to do, but if there will be patch+binary combos, it may work.
>
> i.e. i see that "experimental" subforum as a place for ideas *and* implementations. and implementors can provide built binaries for people to play, or other people can build binaries ('cause if you built it for yourself, why don't share it with others?).
>
> i know that this forum is actually a newsgroup, and it can't host files. but i believe that this problem can be solved -- either by using some simple js-free (for download; yeah, there are such things! ;-) service to host binaries, or by some other means.

Yeah, sounds good, because to make progress, progress has to be made. Most people are very shortsighted and live in a fear based mentality. Mention any type of change and they nearly shit themselves and never actually think about the consequence of those changes. They just assume it means change and it's something they can't handle.

Having an "experimental" D allows those crazy and potentially "mind altering" advancements to be worked on, advanced, and polished. It takes time for ideas to grow(because, ultimately, it involves learning and learning takes time).

So, the good experimental changes will eventually be adopted. Without such a mechanism, they can't EVER be. The problem is that only the core people of D actually get to decide what is good and they tend to push through changes that haven't been well tested(regardless of what they think, D is a prime example by all the miscalculations as is C).

Most people fear growth because growth requires change and change ventures in to the unknown... The unknown is where all the good shit lies and the breakthrough is when someone brings the unknown in to the known.

On Sunday, 11 June 2017 at 00:37:09 UTC, ketmar wrote:
> Adam D. Ruppe wrote:
>> I think dev resources are thin because of mismanagement by the core team failing to attract and retain contributors. Part of this mismanagement is a really discouraging attitude toward positive yet breaking change; I propose that mere willingness to shake up the status quo would help to solve the resource shortage.

+1

> actually, some time ago i proposed to create "experimental and breaking language changes" subforum, where people can go with their wild ideas, and other people can post patches/builds with those (or other) ideas imlemented/half-implemented.

That's called a feature-branch ;-)
The nightlies and CI scripts fully support feature branches since a couple of months (i.e. the same branch is checked out on all dmd, druntime and phobos).
Currently it's only used for `scope` and `newCTFE`:

http://nightlies.dlang.org

Currently not much is happening on these feature branches and thus Martin is running the builds on demand by hand.
However, from a technical point of view, it would be rather easy to use this for more feature branches ;-)

On Sunday, 11 June 2017 at 00:27:06 UTC, ketmar wrote:
> ..and it actually should be D1.5, not D3. ;-) 'cause D3 implies even more features, and i feel that the way to get The Perfect D (sorry! ;-) is trying to cut all the features that aren't strictly necessary (including fat-free stdlib too: i see stdlib as a part of the language).

D1.5? What?  This has nothing to do with D1.  D3 would be forked from D2.  The reason that it would be considered a major version is because it introduces breaking changes.  As far as I know, D2 hasn't been allowed breaking changes since stabilization June 2010.