[cfe-dev] Improving diagnostics when moving standard library headers

[Marshall Clow via cfe-dev]

On Fri, Aug 17, 2018 at 8:40 AM, Louis Dionne via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

>
> On Aug 10, 2018, at 13:30, JF Bastien <jfbastien at apple.com> wrote:
>
>
> On Aug 10, 2018, at 8:39 AM, Keane, Erich via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> Would a better solution be to simply have <experimental/optional> #include
> <optional> (perhaps with some namespace-wrapping?), and in C++17+ mode have
> a #warning instead of that #error?
>
>
> Seems like a better fix, yes.
>
>
> Just to follow up on this. It’s been said before, but the problem is that
> std::experimental::optional and std::optional are not the same thing.
> std::experimental::optional is frozen in time, but std::optional will keep
> evolving. Hence, we would really need to keep providing two implementations
> that may start diverging with time. This is explained here:
> http://libcxx.llvm.org/TS_deprecation.html.
>
> I think what this means is simply that a library that tries to be
> cross-platform and stable through time can’t use experimental features in
> its interface, since those are not guaranteed to be stable. This is
> somewhat unfortunate, but it’s explicit in the fact that those features are
> “experimental”.
>
> The other option would be to do like libstdc++: just keep
> std::experimental::optional around forever, and fork (i.e. copy-paste) that
> code into std::optional. Then, keep evolving std::optional and let it
> diverge from std::experimental::optional. It’s a valid choice to make, but
> it’s not what libc++ is doing because of the reasons explained in
> http://libcxx.llvm.org/TS_deprecation.html.
>
> I personally think that deprecating TSes (what libc++ does) is better in
> the long term — users pay a cost upfront when they need to update, but it’s
> better in the long run because they’re using the “real” standardized
> version of the feature.
>
>
I concur (which is unsurprising, because I initiated the discussion that
led to the current state, and wrote http://libcxx.llvm.org/TS_
deprecation.html )

-- Marshall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180817/144f2187/attachment.html>