RFR: 8369186: HotSpot Style Guide should permit some uses of the C++ Standard Library

[John R Rose]

On Wed, 8 Oct 2025 13:48:09 GMT, Kim Barrett <kbarrett at openjdk.org> 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