On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
> 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.

Here is my suggestion for how to migrate into D3 well, if it were to be done:

First define a "Small D2". The goal of this language is to not really be that much smaller(it could still leave in most of the language, in fact), but to sweep up all the changes breaking with D2 into a form that's clearly less flexible while still being palatable for the majority of modules. It's allowed to be intentionally clumsy and regressive in some ways so that it can be forward-looking later, but not so much so that people don't want to write in it.

Small D2 is given the freedom to do things like regress standard library functions back into hardcoded compiler behaviors, to be more restrictive, to allow less ambiguity, and to generally follow with existing idioms but break the things that needed breaking and leave out the parts that didn't work. The new stuff of Small D2 would be "one-trick-pony" features that bottleneck what can be expressed into a "library" that is actually a compiler hack, or "new syntax" that is actually fake and only allows arbitrary expressions that are already possible in other ways.

Most importantly, Small D2 retains compatibility with regular ("big") D2 modules, so codebases can be migrated into Small D2 piecemeal, while leaving a small remainder to be migrated in a larger way when D3 rolls out. In essence, Small D2 allows the underlying formulation of D to be challenged, but it actually relies on regular D2 constructs internally, so iteration on design can go faster than if we "did it for real". And because Small D2 gives people a taste of new stuff, it will have some instant appeal: People should want to write new code in it, even knowing that it's a hack and less powerful.

Small D2 would be the debate platform for what the "core" of D is. Then, D3 is Small D2 with everything "done for real" this time. Small D2 code migrates forward seamlessly and can continue operating as if nothing happened. The rest of it is considered breaking.

There is already something like D3 exists. https://github.com/VoltLang

On Sunday, 11 June 2017 at 05:03:10 UTC, Suliman wrote:
> There is already something like D3 exists. https://github.com/VoltLang

https://github.com/VoltLang/Watt/blob/97507a202250af96560317f84c29cb2248ae588b/src/watt/algorithm.volt#L37-L91

I don't think so.

Liam McGillivray wrote:

> 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. 

and D1.5 too. sure it should be forked from D2, and then it should be made *smaller*. which, essentially, makes it D1.5, not D3. besides, it will be very fun explaining people that we have D1, then D2, and the newest version is D1.5. people will blog/tweet this, for sure. free PR!

Seb wrote:

> 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 ;-)

not everybody in the world is github-centric.

Mike B Johnson wrote:

> 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).

yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-)

On Sunday, 11 June 2017 at 00:22:50 UTC, 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.

Building on that: 82% of patches for Mozilla Firefox are accepted at first sight. Analysis of the reviews shows that the developper himself often comes back to his patch to correct it before resubmitting it. Such corrections often are due to style because style isn't generally blocking. That said, having worked on Firefox's codebase a fair amount of time I must say that they have one of the cleanest C++ codebase I've ever seen.

The whitepaper is here [1], named "The influence of non-technical factors on code review". I strongly recommend reading it, especially for you Walter and Andrei as I think you might like some of its insights.

There again we are not Mozilla, Phobos is a standard library, a compiler doesn't release every 3 months. But one thing is sure, if Firefox can accept 82% of patches at first sight, if 60% of all patches end up being integrated without resubmission, then the projet size isn't an issue. And before such evidence I am definitely not convinced that it should be hard to introduce a change. What should be hard is introducing a bad one.

(Then again I'm all talk and not wanting to take care of the matter myself so I'm not expecting anything to change just from this post.)

[1]: https://cs.uwaterloo.ca/~rtholmes/papers/wcre_2013_baysal.pdf

On Sunday, 11 June 2017 at 06:14:43 UTC, ketmar wrote:
> Mike B Johnson wrote:
>
>> 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).
>
> yeah. this is exactly the mentality i want to fight with. in my opition, having such forum "officially blessed" will encourage people to experiment. or at least i hope so. ;-)

It's an uphill battle. You are fighting human nature/evolution/ignorance ;/ The good news is that humans are good at mountain climbing when they want to be.

On Saturday, 10 June 2017 at 23:30:18 UTC, Liam McGillivray wrote:
> I realize that there are people who want to continue using D as it is, but those people may continue to use D2.

Well, no thanks.
The very same strategy halved the community for D1/D2 split and almost killed D.

in my opinion starting with D3 is too early, because D-people dont even seem to know how exactly to implement new exciting features like "reference counting" (and how will "reference counting" work together with the new "scope"-feature?).

So, if a D3 gets developed _now_, i guess the compiler developers will create syntax issues again for those features and then we need a D4. Instead it might be better to collect more experience before thinking about D3