[libcxx] r323971 - Remove <experimental/optional>; use <optional> instead. See https://libcxx.llvm.org/TS_deprecation.html

[Nico Weber via cfe-commits]

On Sat, Feb 24, 2018 at 7:17 PM, Marshall Clow <mclow.lists at gmail.com>
wrote:

> On Thu, Feb 22, 2018 at 7:58 AM, Nico Weber <thakis at chromium.org> wrote:
>
>> I have a small personal project where I used to use this. I tried
>> switching to <optional> instead, but that apparently requires -std=c++17.
>> With that, things build fine with my locally-built clang, but latest Xcode
>> clang doesn't accept that flag yet. So I tried -std=c++1z, but latest Xcode
>> (9.2) doesn't even include the <optional> header yet. So now I have no way
>> of being able to build my project with both trunk clang and Xcode clang.
>> Maybe a one-year deprecation period is too short?
>>
>
> Nico --
>
> I'm sorry you were caught out by this.
>
> (It's not a huge deal, I have a optional<> implementation in my project
>> for platforms that don't ship it yet, but things used to be fine on mac
>> until this change at least. It's also not an important project, I just
>> thought I'd point out that this makes life more complicated than it would
>> be if the deletion period was longer.)
>>
>
> Yes, but it also makes life less complicated also.
>
> In fact, optional was the poster child for removing stuff from
> experimental.
> experimental::optional and std::optional have diverged, and are
> significantly different today (and only going to get more different in the
> future)
>
> The cost for someone to move to std::optional will never be lower than it
> is now. (they're only going to become more different).
>
> I really didn't (and don't) want to maintain two closely related (but
> different, and slowly diverging) code bases - and (repeatedly) explain to
> people the difference between them.
>
> As for Apple not shipping std::optional, I too am dismayed by that, but I
> have no control over that. :-(  I don't know when Apple will ship
> std::optional (they don't share their product plans with me), but it
> requires an update to libc++.dylib
>

Does this mean that if I build a mac program with trunk clang and trunk
libc++ using std::optional and -mmacosx-version-min=10.11 (or any other
version), my program will build without problems but then fail to start at
runtime because system libc++.dylib is missing the required optional code?


> , and in the past they have gone *years* without updating the dylib.
>  Hopefully they will update before LLVM 7 ships in August.
>
> -- Marshall
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20180307/6b57ee9f/attachment-0001.html>