On Wednesday, 21 March 2018 at 21:25:55 UTC, Andrei Alexandrescu
wrote:
On 03/20/2018 06:56 PM, Meta wrote:
Does it make sense? In my opinion, no, but according to Andrei
be has tried being less hands-on before and it resulted in
measurably worse quality code in Phobos; thus, he
re-established himself as the gatekeeper. I agree that it
doesn't scale and think that at this point, it's probably
actively hurting Phobos because a lot of good work sits for so
long and eventually becomes abandoned.
On the other hand, it could become much worse for Phobos if he
was entirely hands off and delegated its shepherding to a
larger group of core contributors. A balance has to be struck
somewhere... Maybe a hypothetical group like this needs to be
trained by Andrei such that he can trust them to properly
guide Phobos' development, and will only come to him with the
really big, important stuff.
Thanks for this comment (which is eerily accurate), and thanks
Timothee for raising the matter.
It is an ongoing burden to be the decider on new API additions
to Phobos; indeed I have taken this responsibility because I
have attempted to relinquish it in the past, with negative
results. It is definitely not something that I prefer or enjoy,
and am permanently on the lookout for people with similar
design sensibilities to share the burden with. The door is
open, if not kicked off its hinges. Please take note!
That said, the question of scalability is a bit misplaced. API
additions to Phobos are rare and long-lasting; it is entirely
appropriate to let them ripe a little. In contrast, various
improvements to Phobos - over 100 of them - only need good
reviews, and are obviously bottlenecked by our general lack of
reviewers. That's our real bottleneck. It seems appropriate to
ask the question why we'd ask for acceleration of API additions
without improving response for other work.
I just reviewed https://github.com/dlang/phobos/pull/6178. As
I'd expected, it's good work - which is exactly the matter.
Good work in a submission means most review work. It's not bad
work, which can be easily rejected. And it's not brilliant
work, which can be easily accepted. The PR has bugs and quality
issues that any reviewer could find and provide feedback on.
It's not in the state where it's bottlenecked by just a stamp
of approval.
Naming is a matter I wanted to defer having a debate on. We
should call the facility staticArray to prevent an imaginary
conversation like this:
Q: "So I have a range here, how do I get an array from it?"
A: "Easy, just append .array to it and you're done."
Q. "Cool! Now I need a static array. Wait! Don't tell me, don't
tell me... staticArray is what I should look for!"
A: "Um, no, sorry. That's called asStatic."
Besides, [1,2].asStatic may be guessed right by a reader, but
myrange.asStatic!2 most likely not.
Thanks,
Andrei
Thanks. I stewed on this for a few days, and now it's 3 AM and I
wrote a long reply but deleted it. I agree with most of what you
you've said, and am progressively agreeing less with what I said.
Mostly, I'm just frustrated and don't really have any good
solutions but the PR queue keeps growing. I'll go review
something.
