On Thu, Jul 18, 2024, at 2:03 PM, Lily Bergonzat wrote:
> I would love to see those improvements as well, however I am surprised
> we seem to be more inclined to push a more substantial change than a
> minor one.
>
> I feel like the more substantial one would be more likely to break
> stuff, compared to the minor one, and so I don't see why the minor one
> would be refused?
>
> That said, I am new here, and I do not yet know how things work, so it
> probably is because I lack experience.
As you're new, I'll just note, please don't top post. :-)
The optimal size of an RFC is a very squishy topic. There are some that argue for "the
smallest possible and no smaller," on the theory that bite-sized changes are easier to discuss.
However, they also attract more bikeshedding, and often a feature is not actually useful except in
conjunction with other parts of it. On the flipside, a tiny RFC has a hard time justifying its
existence, since whatever intended follow-ups that would make it actually useful are never
guaranteed to happen (either the authors lose interest or they get voted down later, etc.). Going
through an RFC also has a lot of process overhead, and breaking one small RFC into many tiny RFCs
can actually take far longer than the one larger RFC.
Conversely, an RFC can be too big to really comprehend, and then no one really understands what
it's doing without hours of reading and research, and there's so many moving parts even
the authors cannot keep track of them. On the flipside, some parts just don't make any sense
on their own unless combined with other aspects of a proposal.
So there's really no "natural" size for RFCs generally. It will vary with the topic.
Also, the impact of an RFC often has very little to do with its length or number of features. The
RFC text for "don't require ; to end a statement anymore" would likely be pretty
short, but would also break, er, everything. :-)
Conversely, offering a new syntax for abbreviated constructors (as being discussed here) would be
longer than that, but the impact on existing code would be zero (unless it's done badly).
Also, "minor work" can end up causing problems for future work. See also: readonly, which
was intended as a "junior stepping stone" to more complex features, but as we've
found, actually makes those future features *more* complex because it wasn't designed with
those future expansions in mind.
My own stance (which I do not claim to be universal) is that an RFC is "right-sized" when
it offers notable, meaningful benefit on its own, without "holes" in the functionality,
but can and should have natural "extension points" where it will dovetail nicely with
other, future features, which can be planned or not. Sometimes that means a very short RFC, other
times it means something the size of property hooks. :-) It's really a case-by-case situation.
--Larry Garfield