I'm going to address this post to Walter and Andrei, as the joint captains of the D ship, so to speak.


As an outsider I can see there are two major issues, at play, at present, in this series of threads.

1. The technical proposals and arguments for x & y, or against x & y. On one side is Walter & Andrei with Walters proposal, and the other is Deadalnix.

2. The relationship management, between the co-captains and the community. And the perception of the different rules for the captains verses the community, which causes
resentment, and friction, to members of this community.

I'm not going to discuss item 1 in-depth, because item 2 is far more important.

So let's go back to the beginning.

------------------------

Andrei starts a thread, 4 days ago, titled 'Exceptions in @nogc code'.

    "Walter and I discussed the following promising setup:

    Use "throw new scope Exception" from @nogc code. That will cause the exception to be allocated in a special stack-like region.

    If the catching code uses "catch (scope Exception obj)", then a reference to the exception thus created will be passed to catch. At the end of the catch block there's
no outstanding reference to "obj" so it will be freed. All @nogc code must use this form of catch.

    If the catching code uses "catch (Exception obj)", the exception is cloned on the gc heap and then freed.

    Finally, if an exception is thrown with "throw new Exception" it can be caught with "catch (scope Exception obj)" by copying the exception from the heap into the special region, and then freeing the exception on the heap.

    Such a scheme preserves backward compatibility and leverages the work done on "scope".


----------------------------

Deadalnix enters the discussion in Andrei's thread, with:

    "It doesn't need any kind of throw new scope Exception, and was proposed, literally, years ago during discussion around DIP25 and alike.

    I urge you to reconsider the proposal that were made at the time. They solve all the problems you are discovering now, and more. And, while more complex that DIP25
alone, considering DIP25+DIP1000+this thing+the RC object thing, you are already in the zone where the "simple" approach is not so simple already.

    Things are unfolding exactly as predicted at the time. Ad hoc solutions to various problems are proposed one by one and the overall complexity is growing much larger
than initially proposed solutions."

Others (Eugene Wissner & Dmitry Olshansky) also comment on the proposed syntax.

Walters responds to Deadalnix by asking for more details:

    > It doesn't need any kind of throw new scope Exception, and was proposed,
    > literally, years ago during discussion around DIP25 and alike.

    "A link to that proposal would be appreciated."

Walter adds an additional requirement in response to Deadalnix

    "This does not address the stated need (by many programmers) to not even have to link in the GC code. A solution that falls short of this will be rejected. The
rejections may not be technically well founded, but we're not in a good position to try to educate the masses on this. A solution that does not require linking to the GC
sidesteps that problem."

Walter then adds the following:

    >  I urge you to reconsider the proposal that were made at the time. They solve all
    > the problems you are discovering now, and more. And, while more complex that
    > DIP25 alone, considering DIP25+DIP1000+this thing+the RC object thing, you are
    > already in the zone where the "simple" approach is not so simple already.

    "I did some searching for this previous proposal discussion, but could not find it. Instead, I'll go by your description of it here.

    I've written a more fleshed out proposal and started a new thread with it. Feel free to rip it to shreds! "
------------------------

Walter then starts a new thread, 3 days ago, titled: Proposal: "Exceptions and @nogc". Within the post he lays sub-headings out: Problem; Solution; throw Expression; catch

(Exception e); Chained Exceptions; Copying Exceptions; Legacy Code Breakage; Conclusion; and References. It's like a DIP in structure, but its NOT a formal DIP.

Walters replies to a request by Rikki Cattermole for a DIP.

    >And as probably expected, DIP please. Its a big set of changes and warrants
    > documenting in that form.

    "If it survives the n.g. discussion I will. Though the DIP process is in limbo at the moment since Dicebot is no longer running it."

Here Walter is saying, lets discuss it thoroughly on the n.g. and then LATER, if it's any good, he will formal put it into a DIP.
Fair enough.
----------------------------

Discussions continue.

Deadalix then composes a long reply, in Andreis thread, to Walters request. He is hopeful he will be heard:

    "The forum search isn't returning anything useful so I'm not sure how to get that link. However, it goes roughly as follow. Note that it's a solution to solve
DIP25+DIP1000+RC+nogc exception and a sludge of other issues, and that comparing it to any of these independently will yield the obvious it is more complex. "

[snip]

He posts a link to a Microsoft Research paper.

     "Going into the details here would take too long, so i'll just reference this paper ( https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/msr-tr-2012-79.pdf ) for detailed work in C# about this. This is easily applicable to D."

The PDF is 26 pages long, and very technical.  There is also a link to a Youtube talk that runs for over one hour.

Discussions continue, but Deadalix proposal is not replied to.

I (Nick) after 24 hours, of no response, then ask for a comment from Walter to Deadalix's proposal:

    "Can one assume that Walter is thinking about Deadalnix's detailed proposal above, and that he will give a formal response, once he has given it serious thought, and
discussed it with Andrei ?"

Walter then responds, and gives six counter-arguments to Deadalix proposal, and ends with:

   "This proposal looks promising for making a better garbage collected language, but people want a language with an optional GC."

Deadalix gives counter-arguements.

Walter gives more arguements,and Deadalix replies.

Then Andrei replies, to my post. I will quote in full:

    "As a matter of procedure no, a forum post will not be followed by a formal response. The DIP process ensures a formal response.

    The post is far from what one would call a proposal, let alone a detailed one. It is a sketch of an idea that addresses a complex matter without minding a large number
of details. That's totally fine; the whole discussion opener was also informal and lacking details. It's just that we can't work on someone else's vague idea.

    I encourage anyone interested in pursuing this idea to work on a DIP."

Deadalix, becomes angry at this request for a DIP, again I will quote in full:


    "To be blunt I played the DIP game in the past, never again.

    This is very time consuming and nobody gives a shit. You two just do whatever the heck you want at the end of the day. I'm just pointing I predicted the problem you are
running into with your brilliant approach years before you realized it is a problem. You can decide to not listen, not really my problem.

   I wrote fairly comprehensive specs of the idea in various places, including in the ML you created for this very topic. I just can't be writing specs again and again for
them to be ignored, that's just not a productive use of my time, and at this point I'd even say it's not very respectful to ask people to waste more time.

   I'm happy to work with you guy to come up with something, but I surely won't spend several days working a spec for nothing. "


Walter, gives a  18 lines of reply why he thinks the Deadalix proposal is unworkable.

Walters core objection can be summed up here:

    "For example, adding an `owned` type constructor is a major, major language change. Issues of implicit conversion, overloading, covariance, partial ordering, type deduction, mangling, construction, postblit, TypeInfo, inout, etc., all have to be addressed and worked out. Then there's legacy compatibility, deprecation issues,
interaction with other languages, interaction with multiple storage allocators, etc. "

I will quote the last two lines of Walters reply:

    "Making this work for D involves a great deal of careful design work, and even more implementation work. It also includes some significant risk that it will prove unworkable.

    I don't believe that a back-and-forth disjointed email chain here is going to resolve the major issues with it. Until a far more thorough design proposal is made, I'm going to bow out."

Walter can see what would need to be changed, and the risks involved, but he does not address, in his reply, the proposed benefits raised by Deadalnix, nor the claim it
will solve a number of problems.

As an alternative, Walter could of said, to Deadalnix, give me more detail here, and here, and here. But no, he asks Deadalnix to submit a formal DIP, for he believes the
proposal to be too large and risky.

Finally, Andrei,  replies to Deadalnix, commenting that his previous DIP was of poor quality; on his use of 'crude' language; and stating that he is framing the issue as
part of a larger problem.

Commentary.

I have tried very hard to be objective in this review of these discussions.

But, it seems that while Walter and Andrei are prepared to put a proposal out on the newsgroup, and then discuss it with the community, and then LATER, if its any good,
state they will formally document it into a DIP.

For the community, it seems different rules apply. In-depth news-groups discussions for new proposals are firstly encouraged and then later discouraged, with the ultimate
response that the proposal MUST be in the form of a time-consuming DIP, to be considered, even if it will ultimately wastes everyone time, and cause resentment in the community.

On Thursday, 6 April 2017 at 07:24:28 UTC, Nick B wrote:
> I'm going to address this post to Walter and Andrei, as the joint captains of the D ship, so to speak.
>
> [...]
>
> For the community, it seems different rules apply. In-depth news-groups discussions for new proposals are firstly encouraged and then later discouraged, with the ultimate
> response that the proposal MUST be in the form of a time-consuming DIP, to be considered, even if it will ultimately wastes everyone time, and cause resentment in the community.

Agreed.

I don't want to make any assumptions, and I do respect Walter for consistently taking on a role that means that people keep criticizing his choices whatever he does, but his approach to dealing with the community is undeniably flawed, and seems to be breeding a lot of frustration and resentment.

My personal example is from a discussion we had in February about 'return scope', where Walter Bright asked deadalnix to explain his case, and explain the problems he saw. At the time, deadalnix (and other users) replied that they didn't want to make their cases, because they had already done so in the past, and they expected Walter to ignore whatever they would tell him.

http://forum.dlang.org/post/o6h3re$26lo$1@digitalmars.com

I outlined several problems I saw with return scope, and Walter replied to my post, answering each point I made. And while it's commendable that Walter took the time to do it, those answers felt extremely frustrating to me; Walter did *not* address my points, and did not take what I was saying seriously. As an example, one of the problems I pointed out was:

> It only addresses cases where a reference might be escaped through a single return value; it doesn't address escaping through 'out' parameters,

The following conversation ensued:

Walter:
> Yes it does (the general case is storing a value into any data structure pointed to by an argument).

Me:
> I don't understand. Let's say I have an arbitrary class 'Container', and I want a function that stores a pointer to an int in this container, in a way that lets the function's caller know that the int* given to it will last only as long as the container, and I want to do it without return values. The prototype would be akin to
>
>     void store(ref <scope-info> Container cont, <scope-info> int* ptr);
>
> And the code it would be used in would look like:
>
>     {
>         scope Container c;
>         scope int*      ptr = ...;
>
>         store(c, ptr);
>     }
>
> What would the syntax be?

Walter:
>     c.ptr = ptr;
>
> You can also do:
>
>     ref Container store(ref return scope c, return scope int* ptr);

The rest of the conversation basically went like this:
Me: This isn't possible, or if it is, it shouldn't be.
Walter: Yes it is. It compiles.
Me: Okay, but it shouldn't compile, because it make [invalid write error] possible.
Walter: Well, it doesn't compile with @safe.
Me: Yes, it does compile with @safe, and no, it shouldn't, and my point from the beginning was that your model made that kind of function impossible. Why do you think we're even talking about this?

In short, Walter asked for people to give their opinions on the subject; but when I did give my opinion, Walter did not take my points seriously, and basically assumed that the only reason I disagreed with him was that I didn't understand the subject as well as he did. Other people (including Dicebot) have complained about that.

This was a very frustrating experience, and I did not want to participate in the discussions about Dlang any further after that.

Look, again, I feel bad trash-talking Walter. He's putting a lot of effort into this. But he's clearly really, really bad at listening to other people. This has to be addressed at some point.

On Thursday, 6 April 2017 at 13:55:43 UTC, Olivier FAURE wrote:

> I don't want to make any assumptions, and I do respect Walter for consistently taking on a role that means that people keep criticizing his choices whatever he does, but his approach to dealing with the community is undeniably flawed, and seems to be breeding a lot of frustration and resentment.

IMO the source of the problem is that Walter and Andrei have freedom to make any language changes they want, without even consulting the community, while everyone else has to put a lot of time into a formal proposal with nearly a 100% chance that it will be denied because of [insert your favorite reason]. The design of the language is done in something of a corporate fashion, and that leads to frustrated posts.*

* But not from me.

On 4/6/2017 12:24 AM, Nick B wrote:
> For the community, it seems different rules apply. In-depth news-groups
> discussions for new proposals are firstly encouraged and then later discouraged,
> with the ultimate
> response that the proposal MUST be in the form of a time-consuming DIP, to be
> considered, even if it will ultimately wastes everyone time, and cause
> resentment in the community.

There's one big difference. The proposal I put forth is fairly complete, and I am well along implementing it. deadalnix's requires a great deal of further work just to figure out what it means - as presented, it is not much more than an idea.

Nor is it a simple idea. It will upend D's type system. It'll likely affect much of the semantic code in the compiler, and will require a lot of retrofitting in Phobos. Who knows how extensive that will be.

I don't know any language process that would accept it as it stands - it would get bounced back with "needs more work". Somebody has to work on it to move it forward - who do you propose should do it? We don't have a team anywhere whose job it is to create detailed proposals based on other peoples' ideas (which appear in the forum every day). Things rarely move forward unless a champion for it self-selects with the will and motivation to push it relentlessly.

(The general attitude of the C++ committee is if no champion emerges for a proposal that is willing to fix it and address all concerns about it and fight for it, then the proposal is not worth considering. It works for them.)

If you or anyone else wants to be the champion for deadalnix's idea, I encourage you to do so. Collaborate here or in any way that works for you. I'm not going to shut you or anyone down on such discussions. I have already done a review of it and identified where it needs more work, so the next step is up to you.

(I also did not submit it as a DIP because the DIP process at the time was in limbo due to Dicebot exiting it. Now that Mike Parker is the new DIP czar, things should be moving again.)

On 4/6/17 1:56 PM, bachmeier wrote:
> On Thursday, 6 April 2017 at 13:55:43 UTC, Olivier FAURE wrote:
> 
>> I don't want to make any assumptions, and I do respect Walter for consistently taking on a role that means that people keep criticizing his choices whatever he does, but his approach to dealing with the community is undeniably flawed, and seems to be breeding a lot of frustration and resentment.
> 
> IMO the source of the problem is that Walter and Andrei have freedom to make any language changes they want, without even consulting the community, while everyone else has to put a lot of time into a formal proposal with nearly a 100% chance that it will be denied because of [insert your favorite reason].

We commit to be more formal about the process, but overall it is correct that we have more say in what gets in the language. Allow me to add a couple of things.

First, this is the way things are commonly done in language design - a small committee defines a formal process and ultimately decides on features. In fact it is unusual that we put up unfinished ideas up for discussion, which we hope has the raises the level of responsibility in the community. I understand how what we did has been misunderstood as us just considering ourselves exempt from the due process. We have a very strong interest to follow a formal process and have the trail serve as a template to follow. (That intent is visible in https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md as well, with the unexpected twist of an interesting idea that obsoleted it. The idea has come from Daniel Nielsen in this forum and has been adapted with credit in https://github.com/dlang/druntime/pull/1756.)

Second, we are very much open to increasing the size of our committee. This is already happening - it is obvious that known strong contributors with a good track record and who make consistently valuable have a huge impact on the language and library definition. Fortunately we have quite a few of those. In contrast, our attention is more difficult to be commanded by commentators who have little history of pull requests, good-quality DIPs, articles etc. and attempt to strong-arm us into pursuing underspecified ideas.

Third, all of this is a process not an immutable status. We are learning leadership on the job, and although I think we have made large strides since only e.g. one year ago, there is much more to improve. Expect more changes in the future and please bear with us and grant us your understanding as we are getting the hang of it.


Andrei

On Thursday, 6 April 2017 at 07:24:28 UTC, Nick B wrote:
> But, it seems that while Walter and Andrei are prepared to put a proposal out on the newsgroup, and then discuss it with the community, and then LATER, if its any good,
> state they will formally document it into a DIP.
>
> For the community, it seems different rules apply. In-depth news-groups discussions for new proposals are firstly encouraged and then later discouraged, with the ultimate
> response that the proposal MUST be in the form of a time-consuming DIP, to be considered, even if it will ultimately wastes everyone time, and cause resentment in the community.

Hi,

I am only familiar with the Lua world from a language design point of view - in that world, only the Lua core team decide what features can go into the language. In fact they don't even accept code contributions - everything is coded by the core team - even when they accept an idea.

I don't think a language can be designed by a committee. My impression is that Walter is very decent about replying to criticisms, even though there is no need in my view for him to do so.

I would in fact urge the D team to make it explicit that D language design rests solely Walter and Andrei - and while others can make suggestions as to what should go in, only Walter and Andrei decide what actually goes in.

Regards
Dibyendu

On Thursday, 6 April 2017 at 19:17:53 UTC, Walter Bright wrote:

> There's one big difference. The proposal I put forth is fairly complete, and I am well along implementing it. deadalnix's requires a great deal of further work just to figure out what it means - as presented, it is not much more than an idea.
>
> Nor is it a simple idea. It will upend D's type system. It'll likely affect much of the semantic code in the compiler, and will require a lot of retrofitting in Phobos. Who knows how extensive that will be.

I understand. It was a major change, and you likely felt the risks were not worth it.
>
> I don't know any language process that would accept it as it stands - it would get bounced back with "needs more work".

Yes, but if you had detailed which areas, he might of been more receptive.

> Somebody has to work on it to move it forward - who do you propose should do it? We don't have a team anywhere whose job it is to create detailed proposals based on other peoples' ideas (which appear in the forum every day). Things rarely move forward unless a champion for it self-selects with the will and motivation to push it relentlessly.

That sets a high bar. Can you give an example when this has worked well, or have they been mostly minor changes?
>
> (The general attitude of the C++ committee is if no champion emerges for a proposal that is willing to fix it and address all concerns about it and fight for it, then the proposal is not worth considering. It works for them.)

So this is your and Andreis approach? If so, perhaps you want to document it, so everyone understands.

> If you or anyone else wants to be the champion for deadalnix's idea, I encourage you to do so. Collaborate here or in any way that works for you. I'm not going to shut you or anyone down on such discussions. I have already done a review of it and identified where it needs more work, so the next step is up to you.

No, its his big idea, and I don't understand it well enough to push it.
But I also think that your vision of the language, seems to be fluid at present, with the requirements to support a GC, ARC, and the ability to remove the run-time. Again perhaps you and Andrei want to confirm this direction.

My intent for this post, was to bring to both your attentions, how this was perceived by the outsiders/community, and a perceived (if incorrect) double standard. That was all.

> (I also did not submit it as a DIP because the DIP process at the time was in limbo due to Dicebot exiting it. Now that Mike Parker is the new DIP czar, things should be moving again.)

Good to hear.

On Thursday, 6 April 2017 at 19:27:50 UTC, Andrei Alexandrescu wrote:

> We commit to be more formal about the process, but overall it is correct that we have more say in what gets in the language. Allow me to add a couple of things.
>
> First, this is the way things are commonly done in language design - a small committee defines a formal process and ultimately decides on features. In fact it is unusual that we put up unfinished ideas up for discussion, which we hope has the raises the level of responsibility in the community. I understand how what we did has been misunderstood as us just considering ourselves exempt from the due process. We have a very strong interest to follow a formal process and have the trail serve as a template to follow. (That intent is visible in https://github.com/dlang/DIPs/blob/master/DIPs/DIP1005.md as well, with the unexpected twist of an interesting idea that obsoleted it. The idea has come from Daniel Nielsen in this forum and has been adapted with credit in https://github.com/dlang/druntime/pull/1756.)
>
> Second, we are very much open to increasing the size of our committee. This is already happening - it is obvious that known strong contributors with a good track record and who make consistently valuable have a huge impact on the language and library definition. Fortunately we have quite a few of those. In contrast, our attention is more difficult to be commanded by commentators who have little history of pull requests, good-quality DIPs, articles etc. and attempt to strong-arm us into pursuing underspecified ideas.
>
> Third, all of this is a process not an immutable status. We are learning leadership on the job, and although I think we have made large strides since only e.g. one year ago, there is much more to improve. Expect more changes in the future and please bear with us and grant us your understanding as we are getting the hang of it.

Thank you for the detailed reply.  It helps the understanding by the community.

On 4/10/2017 3:58 AM, Nick B wrote:
>> Somebody has to work on it to move it forward - who do you propose should do
>> it? We don't have a team anywhere whose job it is to create detailed proposals
>> based on other peoples' ideas (which appear in the forum every day). Things
>> rarely move forward unless a champion for it self-selects with the will and
>> motivation to push it relentlessly.
>
> That sets a high bar. Can you give an example when this has worked well, or have
> they been mostly minor changes?

There are many. A random sampling:

Daniel Murphy - moving front end to D
Jacob Carlborg - Objective C support
Stephan Koch - newCTFE
Brad Roberts - autotester, bugzilla
the gdc and ldc teams
Rainer Schutze - GC work, Visual Studio support
Martin Nowak - the releases
Ali Cehreli - book on D
Adam Ruppe - book on D
Jan Knepper - the dlang site server

And a LOT more.

None of them are doing what I told them to do. I didn't pick any of them. They are all self-selected champions. They are what moves D forward.

Pragmatically speaking, the champions are the ones with the most say, because they do the work.

(Even doing the work doesn't guarantee acceptance, but it improves the odds greatly over just posting ideas.)

On Monday, April 10, 2017 15:07:11 Walter Bright via Digitalmars-d wrote:
> On 4/10/2017 3:58 AM, Nick B wrote:
> >> Somebody has to work on it to move it forward - who do you propose should do it? We don't have a team anywhere whose job it is to create detailed proposals based on other peoples' ideas (which appear in the forum every day). Things rarely move forward unless a champion for it self-selects with the will and motivation to push it relentlessly.
> >
> > That sets a high bar. Can you give an example when this has worked well, or have they been mostly minor changes?
>
> There are many. A random sampling:
>
> Daniel Murphy - moving front end to D
> Jacob Carlborg - Objective C support
> Stephan Koch - newCTFE
> Brad Roberts - autotester, bugzilla
> the gdc and ldc teams
> Rainer Schutze - GC work, Visual Studio support
> Martin Nowak - the releases
> Ali Cehreli - book on D
> Adam Ruppe - book on D
> Jan Knepper - the dlang site server
>
> And a LOT more.
>
> None of them are doing what I told them to do. I didn't pick any of them. They are all self-selected champions. They are what moves D forward.
>
> Pragmatically speaking, the champions are the ones with the most say, because they do the work.
>
> (Even doing the work doesn't guarantee acceptance, but it improves the odds greatly over just posting ideas.)

LOL. IIRC, there have been cases where you and/or Andrei have actually tried to get folks to do specific stuff, and it generally hasn't worked. Pretty much everything that gets done around here is because someone steps and does it.

Regardless, because we're all doing this in our free time, what everyone does is going to be highly influenced by what they're interested in or what they need. This does unfortunately tend to result in a number of things not getting done that really should get done (in addition to the issues with everyone finding enough time to do what they're trying to do or whether there are enough people to do what needs doing), but we've gotten a lot of good stuff done around here, because someone decided to step up and champion something, and for better or worse, if no one steps up to champion something, odds are, it doesn't get done.

- Jonathan M Davis