Re: Optional constructor body

On Thu, Jul 18, 2024 at 4:40 PM Larry Garfield <larry@garfieldtech.com> wrote: > > 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 I noted the "don't top-post" earlier, and I was very confused about what it meant. I thought about it for a while and couldn't figure it out so I just figured it was not to me. I understand, now, and I think I am not top-posting right now? Thank you for giving me a nudge. Also thank you for the in-depth explanation about the RFC size. I understand your position now, and I think I mostly agree, fwiw.