clang, c++17, std::optional, and libc++.dylib

[Ken Cunningham]

> On Jul 5, 2020, at 03:13, Ryan Schmidt <ryandesign at macports.org> wrote:
> 
>> On Jul 5, 2020, at 00:33, Ken Cunningham wrote:
>> 
>> It is quite simple (I think) to inline a function implementing bad_optional_access into the <optional> header. That could be used for 10.7 to 10.12, and then all those systems could comfortably implement c++17, and no problem. Otherwise we have to install a newer libc++.dylib on older systems, which is a simple but big problem, as it were.
>> 
>> Here’s the <optional> patch. I only speak basic c++, so improve this if you can.
>> 
>> So I am proposing to use this patch, and disable Apple’s availability test in <__config> for bad_optional_access.
> 
> I can't evaluate the patch, but I just wonder if we have any idea why Apple/LLVM didn't do it that way in the first place. Why did they put it into a new libc++ and cripple the ability to use bad_optional_access on < 10.13? (I wouldn't be surprised if the answer is that they have absolutely no interest in older systems, though that would make me sad.)

There has been a fair amount of housekeeping going on this past 18 months, with lots of  small moves of this type. They might not want to carry baggage into Apple Silicon years. Adding the Arm arch is likely why they dropped i386 support too, I imagine. Three supported arches in the headers and libs is too much.

What I don't know is whether some issue like different libs both throwing the exception would cause confusion if there is an inlined bad_optional_access in 2 places...if that happens to be a problem, my backup plan is to put bad_optional_access into legacysupport perhaps.

K