<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Aug 17, 2018 at 8:40 AM, Louis Dionne via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space"><br><div><span class=""><blockquote type="cite"><div>On Aug 10, 2018, at 13:30, JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>> wrote:</div><br class="m_-2062149429466201366Apple-interchange-newline"><div><div style="word-wrap:break-word;line-break:after-white-space"><br><div><blockquote type="cite"><div>On Aug 10, 2018, at 8:39 AM, Keane, Erich via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br class="m_-2062149429466201366Apple-interchange-newline"><div><div class="m_-2062149429466201366WordSection1" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:"Times New Roman",serif"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">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?</span></div></div></div></blockquote><div><br></div><div>Seems like a better fix, yes.</div></div></div></div></blockquote><div><br></div></span><div>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: <a href="http://libcxx.llvm.org/TS_deprecation.html" target="_blank">http://libcxx.llvm.org/TS_<wbr>deprecation.html</a>.</div><div><br></div><div>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”.</div><div><br></div><div>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 <a href="http://libcxx.llvm.org/TS_deprecation.html" target="_blank">http://libcxx.llvm.org/TS_<wbr>deprecation.html</a>.</div><div><br></div><div>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.</div></div><div><br></div></div></blockquote><div><br></div><div>I concur (which is unsurprising, because I initiated the discussion that led to the current state, and wrote <a href="http://libcxx.llvm.org/TS_deprecation.html" target="_blank" style="color:rgb(17,85,204);font-size:small;background-color:rgb(255,255,255)">http://libcxx.llvm.org/TS_<wbr>deprecation.html</a> )</div><div><br></div><div>-- Marshall</div><div><br></div></div><br></div></div>