Before even contemplating a big disrupting language split like proposed by the OP, wouldn't it first more appropriate to write a nice article, DIP, blog, whatever, listing the defects of the current language that can not be solved by progressive evolution?
I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment.
D is not perfect, no question, but it is not in a state that would jusrify such a harsh approach.

On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:

> I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment.
 I have the same opinion. Raw libraries, poor documentation and infrastructure are much more problematic. If it depended on me, I would declare an embargo on language changes and throw all the forces to eliminate the problems of infrastructure and libraries.

jmh530 wrote:

> Nevertheless, C++ is still a constantly evolving language.

one of the key features of evolution is removing old and rudimentary things. without this, it is not evolution, it is mutilation...

Patrick Schluter wrote:

> Before even contemplating a big disrupting language split like proposed by the OP, wouldn't it first more appropriate to write a nice article, DIP, blog, whatever, listing the defects of the current language that can not be solved by progressive evolution?
> I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment.
> D is not perfect, no question, but it is not in a state that would jusrify such a harsh approach.

the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it).

crimaniak wrote:

> If it depended on me, I would declare an embargo on language changes

that's why we (me, and others like me ;-) need D3. i don't need "better phobos", for example ('cause i'm trying to aboid using phobos anyway), but i really need named arguments (`foo(a:42, b:"hello")`). i want '=>' to be usable for any method/free function, not only for lambdas. i want $-expands in mixin strings. warnings on unary minus on byte/short types (do you know that D doesn't do int promition in this case, and C does? it bites me several times!). i want `foreach_reverse` to be replaced with `foreach (auto a; b; reverse)` (and *require* type, modifier or `auto` there). i want optional `ref` and `out` marks for function *calls*. i want... i want alot of things, i'm not even started yet. especially not started to talk about breaking changes. i cannot do that now (i have my private fork of dmd), 'cause i need to keep compatibility with vanilla, and i have zero hopes to see it all introduced in D2 (language stability, etc.). with D2, i'll have a chance to bring 'em on a table.

On Tuesday, 13 June 2017 at 17:57:14 UTC, Patrick Schluter wrote:
> Before even contemplating a big disrupting language split like proposed by the OP, wouldn't it first more appropriate to write a nice article, DIP, blog, whatever, listing the defects of the current language that can not be solved by progressive evolution?
> I haven't the impression that the *language* itself suffer from so big flaws that it would warrant to fork it in a way that will lead to a lot frustration and bewilderment.
> D is not perfect, no question, but it is not in a state that would jusrify such a harsh approach.

+1
Does anyone currently maintain somewhere such a list of not-gonna-be-fixed-in-D2 defects?
This might provide more solid grounds to this discussion.

On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
> Patrick Schluter wrote:
> the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it).

Can you actually show us examples of what you think needs to break?

Maybe i am too new to D but beyond a few oddities ( std.array needed for string manipulation, ... ) i see not a lot wrong.

Do not underestimate the effect that rewriting a standard library has on a language. Beyond sucking resources away ( D is not a very big community project like Rust ).

Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read.

D its flaws are the Phobos documentation layout ( what is partially solved by the Library documentation ), somewhat lacking support on the editors, and other points. Mostly to do because of the small community/lack of full time paid programmers.

So call me confused as to what is missing and needs such radical changes? Because i can tell clearly from reading past forums, the whole D1/D2 came up in so much topics it actually made me look first into other languages. A D3 discussion is silly given the history of the language.

Unless i am wrong there seem to be only one or two people actually pushing this D3 idea...

On 14/06/2017 8:28 AM, Wulfklaue wrote:
> On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
>> Patrick Schluter wrote:
>> the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it).
> 
> Can you actually show us examples of what you think needs to break?
> 
> Maybe i am too new to D but beyond a few oddities ( std.array needed for string manipulation, ... ) i see not a lot wrong.
> 
> Do not underestimate the effect that rewriting a standard library has on a language. Beyond sucking resources away ( D is not a very big community project like Rust ).
> 
> Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read.
> 
> D its flaws are the Phobos documentation layout ( what is partially solved by the Library documentation ), somewhat lacking support on the editors, and other points. Mostly to do because of the small community/lack of full time paid programmers.
> 
> So call me confused as to what is missing and needs such radical changes? Because i can tell clearly from reading past forums, the whole D1/D2 came up in so much topics it actually made me look first into other languages. A D3 discussion is silly given the history of the language.
> 
> Unless i am wrong there seem to be only one or two people actually pushing this D3 idea...

Don't worry too much about "D3". While I also want a "D3" it won't be a big technical change, much more likely a philosophical change than anything else.

In other words, except for the odd change like final by default for classes(eww), there isn't anything that needs to change for D2. Only smaller improvements which are well worth breaking current semantics.

Wulfklaue wrote:

> On Tuesday, 13 June 2017 at 20:51:37 UTC, ketmar wrote:
>> Patrick Schluter wrote:
>> the main reason for D3 is not language changes, but workarounding "don't break user code" thingy. it is completely impossible to experiment freely or introduce breaking changes in D2 (for a reason, there is nothing bad in it).
>
> Can you actually show us examples of what you think needs to break?

it would be a very long post. ;-) i scratched it a little above, though. my private dmd fork has 100+ patches only to dmd itself, for example, and some are disruptive enough that alot of my code is marked with `module a is aliced;`.

> Frankly one of the reasons why i ended up with D. It has the kitchen and sink, has everything from generics, meta programming and beyond. And the most import factor, it is STABLE. I am working on a big project that needs stability for the next 10+ years. This D3 discussion is discouraging to read.

and one of mine reasons was "yay, it is relatively new, unencumbered with alot of legacy, and *evolving*!" none of it (our reasoning) is better over another. ;-)

> D its flaws are the Phobos documentation layout

one of the things i absolutely don't care about, for example. ;-) besides, dpldocs rox.

> So call me confused as to what is missing and needs such radical changes?

evolving. something very opposite to "stability", as expected by some enterprise users. remember, not all D users are enterprise users. ;-) some of us (me!) came here 'cause D is fun, not 'cause D is "stable", and we may value stability much less than other kinds of users.

> Unless i am wrong there seem to be only one or two people actually pushing this D3 idea...

as for me, i'm not "pushing" it, i am merely "supporting" it. just to make sure that other optinions besides "no, we don't need D3" are not seeing as non-existant only due to their bearers being silent. ;-)

On Wednesday, June 14, 2017 07:28:34 Wulfklaue via Digitalmars-d wrote:
> Unless i am wrong there seem to be only one or two people actually pushing this D3 idea...

It comes up periodically, because there's some change that someone wants that will never make it into D2. Historically, it's the response to most anyone being told that what they want won't make it into D2, and actually, it used to come up quite a bit, but it rarely comes up now. Sure, there are some changes that we'd probably make to the language if we were doing things from scratch or willing to just break every existing D program, but I think that you'd have a hard time getting folks to agree on a list of what would be changed under those circumstances, and for the most part, I think that folks will agree that it's not worth it at this point - certainly, I think that you're going to have a hard time finding any core contributors who think that starting D3 would be a good idea at this point. And I'd be shocked if anyone managed to convince Walter or Andrei that it was a good idea.

Now, there are changes in Phobos which a number of us would like to see that
you'll see a much greater consensus on, some of which aren't likely to be
possible without breaking a lot of code (most notably, the fact that strings
auto-decode to ranges of dchar), which is part of why there was a recent
discussion on creating a new version of Phobos that would eventually replace
the one that we have now
( http://forum.dlang.org/post/volmdaxjihbkpbtplynj@forum.dlang.org ), but
even that discussion didn't exactly gain much traction, and changes that
require massive breakage in Phobos are unlikely to happen, even if we'd very
much like those changes, precisely because they'd cause massive breakage.

It's still possible to make changes in the language and standard library without breaking everyone's code, and there's still plenty of room to make some changes which are breaking changes if they bring enough value, but there's a much greater focus on stability and avoiding code breakage than there used to be, and having the massive breakage of redoing the standard library or moving on to a new version of the language really doesn't fit in with that. And we can do quite a lot in place without such massive breakage. However, some folks are always looking for massive changes in the search of making the language perfect. So, there will likely always be occasional talk of moving on to D3, even if it is unlikely to be on the table any time soon, if ever.

That being said, if you're expecting to be able to write D code and then have it compile 10 years from now with whatever the current compiler is at that time, you're likely to be disappointed. We're targetting stability, and we're better at managing change than we once were, but there are still occasional changes to the language, and even if the standard library is not undergoing massive churn, it does change somewhat over time. If you're maintaining your code and making the occasional, required adjustments when the language or library changes something that requires adjustments, then you should be just fine without having to do massive code rewrites or anything like that (and at this point, breaking changes normally involve a deprecation process so that they don't just force you to immediately change your code). But if you write your code now and try and compile it in a few years without maintaining it in the interim, then you're likely to have at least some code which won't compile anymore.

- Jonathan M Davis