On Wed, 8 Oct 2025 13:48:09 GMT, Kim Barrett <[email protected]> wrote:
>> doc/hotspot-style.md line 1658: >> >>> 1656: to anonymous heterogeneous sequences. In particular, a >>> standard-layout >>> 1657: class is preferred to a tuple. >>> 1658: >> >> I gave this feedback offline, but I'll record it here as well. I think that >> the tuple section should go to the undecided section. >> >> I understand the wish to go with named classes, and I often prefer that as >> well, but I also see that people often refrain from doing using them various >> reasons and instead use out-parameters or mix return values into one >> primitive. I don't want to fully close the door on this feature, and would >> like us to put this in the undecided (yes, still implicitly forbidden) >> section. To me that signals that we can at least experiment with it to see >> if it makes sense to sometimes use it (and if it does we can bring that back >> for discussion). Whereas outright forbidding it puts a stake in the ground >> and tells the story that we really shouldn't be looking at tuples. I think >> that's a too strong of a statement. > > I have a different take on the distinction between forbidden and undecided. I > think of forbidden features as being those where there are good arguments > against. Whereas I think of undecided as perhaps having wishy washy arguments > in either direction, or even not seriously thought about. But good arguments > against can be overcome by better arguments in favor. > > But I can see how someone else might take that distinction differently. > > I also admit to being somewhat biased against tuple in particular. I've seen > a few pretty terrible uses... one was even my fault! > > So okay, I'll recategorize tuple. I'm OK with cracking the door open on tuple, but I have to say I do like API-specific names very much. (And `fst`/`snd` or whatever are not API specific; they are tuple-specific!) So the guidance that steers folks towards name-based techniques, instead of positional techniques, is still sound. I even like out-args, personally, in cases where the out-arg is for a return value that is clearly secondary to the main return value. Example: Main value is boolean, and out-arg is some hint about why the main value is what it is, like a position. The out-arg can also be optional if a null pointer is tolerated (explicitly documented as such, of course), which is useful when the out-arg costs extra to compute. (A separate boolean arg is OK for such uses also, but null pointers are so darn useful as optionality sentinels!) Note that our TRAPS/THREAD macro system can be viewed as a giant set of out-args. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2414737272
