Advent of bugfixes

[Timon Gehr]

On 23.12.19 18:16, berni44 wrote:
> On Monday, 23 December 2019 at 12:02:39 UTC, Timon Gehr wrote:
>> Both of my issues you have attempted to close should not have been.
> 
> Actually, when I remember right, there where three issues, which I 
> closed, because I considered them invalid (and in each of them I gave a 
> reason, why I was doing so), which where reopened by the reporter. [1] 
> [2] and [3]. I still consider two of them invalid, only one of them [3] 
> is from you and maybe I got something wrong there, but as long, as I do 
> understand this issue like I do at the moment I judge it invalid.

That judgement makes no sense, you have not backed it up with anything 
but your own bias, and I feel I have invested appropriate time and 
effort into explaining why. (But I'll try again: You can do something 
that's called a "signed right shift" on an unsigned value and it does 
not matter whether there is a sign bit or not, its definition is based 
purely on the bit representation. You can disagree that this terminology 
makes sense, but it is standard enough to be _explicitly clarified_ in 
the first few sentences of the Wikipedia article I linked, which for me 
is the first result on Google for the query "signed right shift" [1]. 
Why is it not disrespectful to ask me to do this Google search for you?)

If for the original reporter, the required action was indeed as simple 
as just reopening the issue, Steve's argumentation would make a little 
more sense.

> The 
> other one from you [2] got a separate thread in this forum. After you 
> clearified it there, I understood, what you wanted and filed a PR which 
> exactly does, what you want (and it would probably allready be merged, 
> if dup would not have been down).

Yes, that PR seems close enough. However, I basically spent an entire 
day fighting against misconceptions in that thread (which is to a large 
extent my own fault, of course, I cared too much). The amount of 
additional work that resulted for me is not nearly proportional to the 
impact of the PR. Thanks though; that PR _will_ have an actual impact.

> And for reference, in [1] the reporter 
> arguments, that we should add a bug, for consistency with an other bug; 
> at least, that's my perception.
> ...

The behavior you call "an other bug" is explicitly documented. The 
Phobos documentation plainly states:

https://dlang.org/library/std/conv/to.html
"* Unsigned or signed integers to strings.
[special case]
Convert integral value to string in radix radix. radix must be a value 
from 2 to 36. value is treated as a signed value only if radix is 10. 
The characters A through Z are used to represent values 10 through 36 
and their case is determined by the letterCase parameter."

I don't know if that's the best possible design, but it makes sense for 
common bases like 2, 8 and 16. Certainly not a bug though.

There is no related documentation about std.conv.parse that I could 
find, but the fact that it doesn't consume its argument in case it 
starts with a "-" and (only) if the radix is not 10 is a very strong 
hint that it should be roundtrip-compatible.

I.e., leave that bug report open or fix the issue. There's no reason to 
harass the original reporter about it any further. The issue is that you 
didn't think to pull out the related documentation. You wanted to close 
a bug report about std.conv.parse without understanding the (admittedly 
not fully intuitive) interfaces of std.conv.to and std.conv.parse. There 
is no good reason for you to do this though, I think you could easily do 
better. It's a matter of following the right process. (E.g., once you 
think someone is wrong about something, try to refute your own opinion 
and only if you fail to do that, write your post. It helps to include a 
trusted third-party source that the other person can then use to refute 
their own opinion, but if it is the first result in a popular search 
engine, I think it is justifiable to be a bit grumpy about being forced 
to bear the burden of proof.)

>> it appears your judgement can be rather biased towards closing issues.
> 
> I found several bug reports, where I think, that they could be closed 
> too, but where I felt, that I cannot decide upon. In most cases I wrote 
> a question, asking for clearification, sometimes I just ignored them. 
> But well yes, I might have made mistakes. That's normal, because I'm a 
> human being.
> ...

So am I, but whether you are human or not is not a particularly 
important parameter. If you are _fallible_, there's typically a 
trade-off between time invested and number of mistakes. Valid bug 
reports have high positive value and invalid ones are only slightly 
negative. Therefore, it pays to be careful about what you close.

If you have a team of people working on something (particularly code or 
research), and different people apply different amounts of care, there 
is bound to be a certain amount of conflict about it, and if careless 
people don't adapt, the careful ones eventually leave or burn out. I am 
not the bad guy here, and I think your intentions are good as well. I'm 
just telling you how to be more effective at transforming your labor 
into actual value. Andrei wrote a related post some time ago, though it 
is not a perfect fit [2].

> [1] https://issues.dlang.org/show_bug.cgi?id=18290
> [2] https://issues.dlang.org/show_bug.cgi?id=7006
> [3] https://issues.dlang.org/show_bug.cgi?id=8007
> 
> 

[1] https://en.wikipedia.org/wiki/Arithmetic_shift
[2] https://forum.dlang.org/thread/q6plhj$1l9$1@digitalmars.com?page=15