> On Jul 5, 2020, at 03:13, Ryan Schmidt <[email protected]> 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
