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

[Johan Sjölen]

On Wed, 8 Oct 2025 18:48:12 GMT, John R Rose <jrose at openjdk.org> wrote:

>> 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.

Often, we can use more "specialized" tuples like `Maybe<T, Error>`, in which case it's fine to have the 'generic' `_value`, `_error` slots. Having a bigger sign saying "hey, hey!! this might fail!!!!" is good, it makes bugs related to missing error handling more shallow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27601#discussion_r2425580500