[libcxx] r323971 - Remove <experimental/optional>; use <optional> instead. See https://libcxx.llvm.org/TS_deprecation.html
Nico Weber via cfe-commits
cfe-commits at lists.llvm.org
Wed Mar 7 11:24:37 PST 2018
On Sat, Feb 24, 2018 at 7:17 PM, Marshall Clow <mclow.lists at gmail.com>
> 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::optional and std::optional have diverged, and are
> significantly different today (and only going to get more different in the
> 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...
More information about the cfe-commits