<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><br><div>On Jun 15, 2017, at 22:22, Eric Fiselier <<a href="mailto:eric@efcs.ca">eric@efcs.ca</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 15, 2017 at 11:00 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</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">Your suggestion is essentially to replace experimental/string_view with something like:<div><br></div><div> namespace std { inline namespace __1 { namespace experimental {</div><div> template <class CharT></div><div> using basic_string_view = _VSTD::basic_string_view;</div><div> }}}</div><div><br></div><div>That breaks:</div><div>1. User compiles 1.cpp with older toolchain. 1.cpp implements foo(std::experimental::string_<wbr>view).</div><div>2. User compiles 2.cpp with newer toolchain. 2.cpp calls foo(std::experimental::string_<wbr>view).</div><div>3. User links 1.o with 2.o.</div><div><br></div><div>I'm not sure if this matters.</div></div></blockquote><div><br></div><div>It can't matter. <experimental/foo> are allowed to break both their API and ABI as needed.</div><div><br></div><div>Also I was suggesting </div><div><br></div><div> namespace std { namespace experimental {</div><div> using std::basic_string_view;</div><div> using std::string_view;</div><div> }}</div><div> </div><div>This approach will break code that expects experimental::string_view and std::string_view are different types:</div><div>Example:</div><div><br></div><div> void foo(std::string_view);</div><div> void foo(std::experimental::string_view);</div><div> foo(std::string_view{}); // ambiguous</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div><div><div><span class=""><blockquote type="cite"><div>On Jun 15, 2017, at 21:55, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:</div><br class="m_5535665134301237518Apple-interchange-newline"><div><div dir="ltr">I would also want to do serious performance analysis on this patch. Does removing the string_view overloads cause less optimal overloads to be chosen? Perhaps allocating ones?<div>That would be really unfortunate, and I'm not sure that's in the best interest of our users at large.</div></div></div></blockquote><div><br></div></span><div>Less optimal compared to what? C++17 code?</div></div></div></div></div></blockquote><div><br></div><div>Not sure yet, I'm trying to figure out what types the `const Tp&` overloads</div><div>are attempting to soak up. Is it only string_view? </div></div></div></div></div></blockquote><div><br></div><div>The type trait restricts it to things convertible to string_view that are not const char *.</div><br><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div><div><div class="h5"><br><blockquote type="cite"><div><div dir="ltr"><div>/Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 15, 2017 at 10:51 PM, Duncan P. N. Exon Smith <span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</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"><br><div><span><blockquote type="cite"><div>On Jun 15, 2017, at 19:42, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:</div><br class="m_5535665134301237518m_3829869060949612838Apple-interchange-newline"><div><br class="m_5535665134301237518m_3829869060949612838Apple-interchange-newline"><br 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"><div class="gmail_quote" 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">On Thu, Jun 15, 2017 at 8:38 PM, Duncan P. N. Exon Smith<span class="m_5535665134301237518m_3829869060949612838Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span><span class="m_5535665134301237518m_3829869060949612838Apple-converted-space"> </span>w<wbr>rote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">I just started working on a patch to add #if guards, and the first interesting thing I found was the basic_string constructor:<div><br></div><div><div></div><blockquote type="cite"><span><div>template <class _CharT, class _Traits, class _Allocator></div></span><div>template <class _Tp></div><div>basic_string<_CharT, _Traits, _Allocator>::basic_string(</div><div> const _Tp& __t, size_type __pos, size_type __n, const allocator_type& __a,</div><div><span class="m_5535665134301237518m_3829869060949612838m_8776782733827039247Apple-tab-span" style="white-space:pre-wrap"> </span><span class="m_5535665134301237518m_3829869060949612838Apple-converted-space"> </span>typename enable_if<__can_be_converted_t<wbr>o_string_view<_CharT, _Traits, _Tp>::value, void>::type *)</div><div> <span class="m_5535665134301237518m_3829869060949612838Apple-converted-space"> </span>: __r_(__second_tag(), __a)</div><div>{</div><div><span class="m_5535665134301237518m_3829869060949612838m_8776782733827039247Apple-tab-span" style="white-space:pre-wrap"> </span>__self_view __sv = __self_view(__t).substr(__pos, __n);</div><div> <span class="m_5535665134301237518m_3829869060949612838Apple-converted-space"> </span>__init(__sv.data(), __sv.size());</div><div>#if _LIBCPP_DEBUG_LEVEL >= 2</div><div> <span class="m_5535665134301237518m_3829869060949612838Apple-converted-space"> </span>__get_db()->__insert_c(this)<wbr>;</div><div>#endif</div><div>}</div></blockquote><div><br></div></div></div></blockquote><div><br></div><div>That constructor was added in C++17, so removing it along with string_view should be OK.</div><div>Assuming we don't use it to implement older constructors using a single template.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div><div>I suppose the decision was made so that std::string could take advantage of it.</div><div><br></div><div>Is it a conforming extension?</div></div></div></blockquote><div><br></div><div>No, because it can change the meaning of otherwise well defined code, as you pointed out initially. </div></div></div></blockquote><div><br></div></span><div>Let me know if this patch is along the right lines. If so, I'll finish it up and put it on phab.</div><div><br></div><div>experimental/filesystem/path.c<wbr>pp doesn't compile, since experimental/filesystem uses things like operator+=(string, string_view) extensively. But I'd like an early opinion on the approach before I dig in.</div><div><br></div><div>In string, the only function that needed to be rewritten was string::compare(size, size, string, size, size). I'm nervous that filesystem will be a bigger job.</div><div><br></div><div></div></div></div><br><div style="word-wrap:break-word"><div><div></div><br><blockquote type="cite"><div><div class="gmail_quote" 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"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div class="m_5535665134301237518m_230594884939490540h5"><div><br></div><div><blockquote type="cite"><div>On Jun 15, 2017, at 18:35, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:</div><br class="m_5535665134301237518m_230594884939490540m_8776782733827039247Apple-interchange-newline"><div><div dir="ltr">It *shouldn't* include <string_view>, that's a given.<div><br></div><div>IIRC, and Marshall would know better, I believe it was untenable to</div><div>maintain a version of <string> that didn't depend on <string_view> after making</div><div>the changes required for C++17.</div><div><br></div><div>However inspecting <string> now it does seem possible that the entanglement</div><div>is avoidable.Though it's also likely I'm just not seeing the whole picture. </div><div><br></div><div>/Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 15, 2017 at 6:42 PM, Duncan P. N. Exon Smith<span class="m_5535665134301237518m_230594884939490540Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:dexonsmith@apple.com" target="_blank">dexonsmith@apple.com</a>></span>wr<wbr>ote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span><br>> On Jul 20, 2016, at 22:31, Marshall Clow via cfe-commits <<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>> wrote:<br>><br>> Modified: libcxx/trunk/include/string<br>> URL:<span class="m_5535665134301237518m_230594884939490540Apple-converted-space"> </span><a href="http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/string?rev=276238&r1=276237&r2=276238&view=diff" rel="noreferrer" target="_blank">http://llvm.org/viewvc/ll<wbr>vm-project/libcxx/trunk/includ<wbr>e/string?rev=276238&r1=276237&<wbr>r2=276238&view=diff</a><br>> ==============================<wbr>==============================<wbr>==================<br>><br></span><span>> @@ -435,6 +461,7 @@ basic_string<char32_t> operator "" s( co<br>> */<br>><br>> #include <__config><br>> +#include <string_view><br><br></span>This breaks the following, valid, C++14 code:<br><br> <span class="m_5535665134301237518m_230594884939490540Apple-converted-space"> </span>#include <string><br> <span class="m_5535665134301237518m_230594884939490540Apple-converted-space"> </span>#include <experimental/string_view><br> <span class="m_5535665134301237518m_230594884939490540Apple-converted-space"> </span>using namespace std;<br> <span class="m_5535665134301237518m_230594884939490540Apple-converted-space"> </span>using std::experimental::string_view<wbr>;<br> <span class="m_5535665134301237518m_230594884939490540Apple-converted-space"> </span>void f() { string_view sv; }<br><br>Should <string> #include <string_view> even when we're not in C++17 mode? Why?<br><div class="m_5535665134301237518m_230594884939490540m_8776782733827039247HOEnZb"><div class="m_5535665134301237518m_230594884939490540m_8776782733827039247h5"><br>> #include <iosfwd><br>> #include <cstring><br>> #include <cstdio> // For EOF.</div></div></blockquote></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></blockquote></div><br></div><br></blockquote></div><br></div>
</div></blockquote></div></div></div><br></div></div></div></blockquote></div><br></div></div>
</div></blockquote></body></html>