RFR: 8314488: Compiling the JDK with C++17

[Andrew Haley]

On Sat, 16 Aug 2025 12:03:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I've had variations of this conversation a number of times with various
>> HotSpot folks. The upshot has always been that the preferred approach is that
>> a function returning multiple values should return a named class/class
>> intended for that purpose, with named and typed members/accessors. (Or
>> probably even more often, a value and out parameters. Though I personally am
>> not a big fan of those, esp. out reference parameters.) Names and types are
>> more meaningful than offsets and implicit types. There are folks who strongly
>> dislike that some of the standard library functions return `std::pair` because
>> `first` and `second` members don't carry any useful information.
>> 
>> For the specific case of "value | error-value" I'd personally prefer we
>> pursued something in the direction of boost.leaf, boost.outcome, or
>> std::expected. (I think all of these can be significantly trimmed down if one
>> only wants to support a fixed restricted type of error-value, like an error
>> code. I think that's even the recommended style for boost.outcome?)
>
> You are, of course, free to argue the contrary, and that we should allow the
> use of structured bindings (or any other categorization in this list or
> elsewhere in the style guide). If you find there is sufficient support, we can
> change things. (I personally don't have a strong opinion either way about
> structured bindings. I put it in the forbidden column because I know there are
> some folks who would be strongly opposed. I've not had anyone express to me a
> strongly favorable opinion, but that doesn't mean they aren't out there.)

> I've had variations of this conversation a number of times with various HotSpot folks. The upshot has always been that the preferred approach is that a function returning multiple values should return a named class/class intended for that purpose, with named and typed members/accessors. (Or probably even more often, a value and out parameters. 

Mmm, agree, but that's a lot of ceremony for such a simple thing; and to avoid that ceremony people may designate a sentinel value as meaning "fail".

> Though I personally am not a big fan of those, esp. out reference parameters.) Names and types are more meaningful than offsets and implicit types. There are folks who strongly dislike that some of the standard library functions return `std::pair` because `first` and `second` members don't carry any useful information.

Fair.

> For the specific case of "value | error-value" I'd personally prefer we pursued something in the direction of boost.leaf, boost.outcome, or std::expected. (I think all of these can be significantly trimmed down if one only wants to support a fixed restricted type of error-value, like an error code. I think that's even the recommended style for boost.outcome?)

Sure. Boost.leaf looks nice, but I tend to prefer a language's standard way of doing things. But if there's a lightweight generally-applicable idiom we can use, I'm happy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25992#discussion_r2280468513