Walter and Andrei and community relationship management

[Nick B via Digitalmars-d]

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.