I approved DIP1036e

[Adam D Ruppe]

I unsubscribed from this forum, since I find it to make me angry 
and not lead anywhere productive, but people linked me to this so 
I'll give one more reply to set the record straight.

There's a ST:TNG scene that comes to mind relating to all this:

https://www.youtube.com/watch?v=Owyj_5TuHQw

"It's not you I hate, Cardassian. I hate what I became because of 
you."

I used to be nice to people online. I used to not cuss online. I 
kinda miss the old me.

On Thursday, 18 January 2024 at 16:31:11 UTC, Mike Parker wrote:
> Adam was unhappy that Walter wanted a spec, so Atila agreed to 
> put the editions proposal on hold to get it done (and please, 
> let's not rehash the argument about reading code vs. writing 
> specs).

It was never about reading code vs writing specs. Let's review 
the facts.

I published an implementation *in an effort to clarify an 
existing spec* - implementing the YAIDIP as written by John 
Colvin and Andrei Alexandrescu, which is an evolution of DIP1027 
- on October 19th. https://github.com/dlang/dmd/pull/15714

In the process of working with that implementation, I found flaws 
in the design (in particular, it was incapable of handling tuple 
arguments, which includes nested strings, because they threw off 
the odd-even rule specified) and fixed them in a separate branch 
on October 20th (note that there are other potential ways to fix 
this issue, but since this was already a solution we debated and 
found working during the original dip1036 review, I stuck with it 
- that's why the PR is called "1036e", since it built on those 
existing principles). https://github.com/dlang/dmd/pull/15715

Note that DIP1036 was written primarily between September 2020 
and March 2021. This is not a new topic, many of us have spent a 
significant amount of time on the topic over a period of many 
years. 
https://github.com/dlang/DIPs/blob/344e00ee2d6683d61ee019d5ef6c1a0646570093/DIPs/DIP1036.md

There are, of course, several differences between the PR and the 
original dip1036 (whereas PR 15714 kept quite strictly to the 
YAIDIP's text), but we'll get to those soon.

So, remember, the code was written on October 20th.

To better show how the feature works in practice, I wrote the 
first of several user-facing examples on October 21st. 
https://github.com/adamdruppe/interpolation-examples/commit/ca4441508c9726519e769184cc7314fc0bf146b7

On October 23rd, Walter stated that the PR "Lacks 1: complete and 
accurate specification, or even a description. 2: comments. 3: 
test cases". 
https://github.com/dlang/dmd/pull/15715#pullrequestreview-1693080343

(Frankly, I think that very request is obnoxious, because on 
October 22nd, Walter posted his dip1027 implementation. I've said 
before that him doing this is a real slap in the face of the 
whole DIP process - his DIP was reviewed and rejected. He's been 
beating that dead horse for many, many years, never 
incorporating... or even *acknowledging* the feedback from 
reviewers. You probably recall my listing the receipts for this 
on New Year's Eve.

But nevertheless, compare the first draft of PR 15722 with the 
first draft of PR 15715. They're very similar, down to the 
semantic function both using the same `new MixinExp` hack (well, 
I thought it was a hack, until I saw Walter did it the same way, 
so apparently he thought it was a decent way to do it!). So I 
found it difficult to believe he was simultaneously capable of 
writing one implementation and incapable of understanding an 
independent, yet *very similar* implementation. Even if there 
were questions, he surely has significant foundation to ask them 
specifically and engage in a productive dialog. But instead, it 
was a vague drop and run. This is why there's an "us vs them" 
mentality - Walter acts not like a partner for peace, but rather 
as an obstacle to overcome. The DIP process structurally 
reinforces this - he is like the final boss to defeat after a 
grueling gauntlet to get to the prize.)

However, despite my skepticism, on October 24th, I started 
fulfilling that request, adding the first tests, which also 
double as basic documentation and examples on the compiler side, 
showing some specific edge cases that differentiate it from the 
original dip1036 text. 
https://github.com/dlang/dmd/commit/75f6f326695b5354c9ffb38ed4ec47b057881549

Additionally, on October 24th, I edited the first comment on the 
PR to incorporate a plain text description (similar in style to 
Walter's 1027 PR's introduction). (Click the "edited" drop down 
on the comment on Github to see the history with dates attached. 
Note that at the time Walter made the request, the plain text 
description was indeed not there. But shortly after he requested 
it, I edited it in to be easy to find.)

I added additional documentation, both comments on the 
implementation, more tests for specific edge cases that needed 
clarification, and VERY IMPORTANTLY a full user-facing 
documentation page on *October 26th*. 
https://github.com/dlang/dmd/commit/2ff8e2d1598d4b2cd581320095f526c8547c2c46#diff-22dd3c85816b0aa6351d1bc21e72ed410b509f8f7c768db3dd974967751b37e1

I've posted this link several times, and never got an 
acknowledgement from any of you that it exists.

Click that. Check the date on it. Read the contents on it. This 
is NOT code one has to reverse engineer. This is a description, 
written up as a standard D documentation block, for users to 
understand how the feature works.

Again, THIS IS NOT ASKING SOMEONE TO REVERSE ENGINEER THE CODE 
nor is it true that I refused to write documentation. There ARE 
examples, tests, comments, and two plain text descriptions, one 
aimed at the code reviewer and one aimed at the end user.

This is the #1 thing driving me nuts about this whole thing. 
Walter requested a description on Monday, October 23rd. I 
answered that request by *Thursday, October 26th*. The examples 
and documentation I wrote over those three days form a 
significant fraction of Atila's DIP text! 
<https://github.com/atilaneves/DIPs/blob/string-interpolation/Interpolation.md> (This dip was mostly written between December 18th and present day.)

Then, when we were on the DLF call on November 10th, more than 
two weeks AFTER I had *already written the requested 
documentation*, Walter again demanded a nebulous "spec" instead 
of engaging with the work that was already done.

I'd say "you have no idea how angry this makes me", but you were 
on that call. You certainly have some idea of how angry it makes 
me.

Now, I confess, my kneejerk reaction on that call, the sudden 
outburst of anger, was not an ideal response. I'm ashamed of the 
angry outburst. It surprised even myself. I was otherwise 
prepared with the documentation and examples written, but I was 
evidently not emotionally prepared.

Nevertheless, can we please, PLEASE, finally acknowledge the 
*verifiable fact* that I did NOT refuse to write documentation, 
but rather quite the contrary, actually *did* write the requested 
documentation within 72 hours of receiving the request.

If you all have a specific problem with this, you never 
communicated what it is. Do you (plural you, not you 
specifically, Mike) just not know it exists? Do you find the 
formatting unacceptable? The content insufficient? If so, in what 
way?

I'm actually inclined to think it you all honestly don't even 
know it is there. This would be consistent with many other cases 
where leadership made a request, the request was fulfilled, then 
silence. There's little follow-up.

You might notice that on those DLF calls, I prepared ahead of 
time for each one, starting with follow up on old business, then 
introducing new business. I kept the notes from the previous 
meeting and checked the links ahead of time so I could see what 
was done and what still needed to be done.

I suggest you do the same. But not just with meetings. Do it with 
any time - when you request something, put a note on your 
calendar to follow up on it some time later. In fact, it is best 
to communicate your schedule to the person you're requesting, 
such as "This needs documentation and test. I will check back in 
on Friday."

That's actually one useful bit of deadlines: they're a good time 
to schedule the follow up. Look back at the original request and 
see if it was done. E.g., reload the pull request page and glance 
it over for new pushes, then you can talk to the person you 
requested the work out of, knowledgeable of what was done to keep 
the conversation on topic and productive.

IIRC this was the key feature of the DIP redesign back when 
Dicebot proposed it - the old dips, before dip1000, were often 
left in limbo. The new process, with you taking up the role as 
dip manager, included various steps and timeframes to ensure 
something happened.

The new DIP process has also failed - i think the us-vs-them 
structure, frontloading the grinding work just to have it 
dismissed or misunderstood in an adversarial battle instead of 
refined in a cooperative, iterative process is the key to why - 
but ensuring you do get an answer in a predictable timetable is a 
good idea.


Anyway, I'm going back off this forum too. I have better things 
to do than argue in circles again as well.