On 4/14/2017 7:27 AM, Joseph Rushton Wakeling wrote:
> Even allowing for the fact that changes to the language definition should face a
> high bar (made higher by the general wish for non-breaking changes), that
> suggests that the 'champion'-based approach may run into difficulties when it
> comes to more fundamental contributions to the D language.

Fundamentally changing the language is a major undertaking. The language is complicated, there's a lot of baggage, and the reason things are the way they are is usually unclear. Having a handwavy post proposing such things is just not good enough.

It's a fact of life that 99% (made up number) of fundamental language change proposals are going to fail. What an intractable mess D would be if the daily stream of language proposals were implemented. I have more than enough trouble with regressions caused by previous language changes.

Nevertheless, if you peruse the PRs, a number of language changes have been made by various champions. There is the way import lookups are done now - a change implemented by myself and Martin, but proposed by others. The way Ddoc works has been altered significantly by others, such as having runnable embedded example code. Kenji made many subtle changes to how templates work.

I read deadalnix's posts. I pointed out major unaddressed issues, like how does it deal with an application using multiple independent methods of allocating memory.

If you or anyone else want to self-select as the champion for it to make it more complete, that's how things work. I work every day trying to keep D moving - I spent yesterday updating the /dmd/samples so they work again, nobody else wanted to do it. I also spent much time yesterday figuring out why Windows DLL support broke again. Nobody else was going to do that. I simply cannot turn every idea posted here into a detailed proposal.

Keep in mind that other languages, such as C++, will not even look at any proposals that are not detailed and complete. And that's just the start of a pretty brutal winnowing process. Their position is that if the proponent of a change is not willing to put in the work to make a detailed proposal, why should it be worth their time to investigate it? It can't work any other way.

On 15/04/17 00:09, Walter Bright wrote:

> I read deadalnix's posts. I pointed out major unaddressed issues, like
> how does it deal with an application using multiple independent methods
> of allocating memory.

Do you have a link? I certainly think his direction rings of better engineering than the road you are trying to take right now, and I might try to pick it up myself.

> Keep in mind that other languages, such as C++, will not even look at
> any proposals that are not detailed and complete.

While nothing there is perfect, I don't agree with that point. Language changes are being proposed on the mailing list all the time. Many of them are very very very *very* far from being complete, and a discussion is what happens next. Very few of those ideas actually make it into proposals.

I'm not saying that the C++ way is perfect, or even necessarily better. Just that your point of comparison is stating incorrect facts.

Shachar

On Friday, 14 April 2017 at 21:09:23 UTC, Walter Bright wrote:
> Fundamentally changing the language is a major undertaking. The language is complicated, there's a lot of baggage, and the reason things are the way they are is usually unclear. Having a handwavy post proposing such things is just not good enough.
>
> It's a fact of life that 99% (made up number) of fundamental language change proposals are going to fail. What an intractable mess D would be if the daily stream of language proposals were implemented. I have more than enough trouble with regressions caused by previous language changes.

I'm not disputing that, and I would always defend your right, as the person with ultimate responsibility for the language, to have the ultimate veto.

> Nevertheless, if you peruse the PRs, a number of language changes have been made by various champions. There is the way import lookups are done now - a change implemented by myself and Martin, but proposed by others. The way Ddoc works has been altered significantly by others, such as having runnable embedded example code. Kenji made many subtle changes to how templates work.

Out of curiosity -- when did these things happen, and what was the process people went through?  It could be interesting to understand if these contributions were easier because they occurred at a time when the language definition was less well defined and so it was easier to champion changes.

> I read deadalnix's posts. I pointed out major unaddressed issues, like how does it deal with an application using multiple independent methods of allocating memory.

To be clear -- I don't want to make this about the specifics of Deadalnix's proposal.  I chose to use that as an example for discussion ... on which I'll follow up in reply to your next remarks:

> If you or anyone else want to self-select as the champion for it to make it more complete, that's how things work. I work every day trying to keep D moving - I spent yesterday updating the /dmd/samples so they work again, nobody else wanted to do it. I also spent much time yesterday figuring out why Windows DLL support broke again. Nobody else was going to do that. I simply cannot turn every idea posted here into a detailed proposal.
>
> Keep in mind that other languages, such as C++, will not even look at any proposals that are not detailed and complete. And that's just the start of a pretty brutal winnowing process. Their position is that if the proponent of a change is not willing to put in the work to make a detailed proposal, why should it be worth their time to investigate it? It can't work any other way.

I agree that, broadly, this is how things need to work, and I'm not suggesting that it should be your responsibility to take other people's skeleton ideas and flesh them out.  But note that C++'s process is possible at least partly because there is such a scale of people involved, that probably (i) they _have_ to operate this brutally just in order to get the number of proposals down to a manageable scale, and (ii) there's always going to be another person willing to pick up a good idea, if the original proponent drops out.

What I'm suggesting (and I won't repeat myself from my post above <https://forum.dlang.org/post/cwoezrgcspdoibmrwkuc@forum.dlang.org>) is not that you load yourself with even more work, but just to consider some specific short-term measures to try to raise the level of confidence people have in engaging with process.

I.e. invest in changing people's perceptions of process now, to drive much more productive engagement with process in future.