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

[Kim Barrett]

On Sat, 16 Aug 2025 09:07:17 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> I'm hijacking the PR mechanism as a way to discuss new C++17 features that can
>> be more easily structured and captured than bare email. Once discussion
>> settles down I'll turn the results into HotSpot Style Guide changes. I don't
>> intend to integrate any version of this document to the OpenJDK repository.
>
> doc/cpp17-features.md line 412:
> 
>> 410: [p0144r0](http://wg21.link/p0144r0)
>> 411: [p0217r3](http://wg21.link/p0217r3)
>> 412: 
> 
> It might well be worth allowing limited used of Structured Bindings. The ability to return a status from an incomplete function is something we've lacked:
> 
> 
> std::tuple<double, bool> incomplete_function(double x) {
>   if (x >= 0)
>     return std::tuple(sqrt(x), true);
>   return std::tuple(x, false);
> }
> 
>   const auto[root, failure] = incomplete_function(d);
>   if (failure) {...

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?)

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

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