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.
