On Wed, 8 Oct 2025 18:48:12 GMT, John R Rose <[email protected]> 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
