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
