<div dir="ltr">I should mention that <experimental/filesystem> depends on C++17 string_view in older dialects :-S<div>So this change will break that.</div><div><br></div><div>I would prefer to fix your specific use case by making std::experimental::string_view literally be</div><div>std::string_view. </div><div><br></div><div>/Eric</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jun 15, 2017 at 8:42 PM, Eric Fiselier <span dir="ltr"><<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Thu, Jun 15, 2017 at 8:38 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">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_-7388923065028223553m_8776782733827039247Apple-tab-span" style="white-space:pre-wrap"> </span> typename enable_if<__can_be_converted_t<wbr>o_string_view<_CharT, _Traits, _Tp>::value, void>::type *)</div><div> : __r_(__second_tag(), __a)</div><div>{</div><div><span class="m_-7388923065028223553m_8776782733827039247Apple-tab-span" style="white-space:pre-wrap"> </span>__self_view __sv = __self_view(__t).substr(__pos, __n);</div><div> __init(__sv.data(), __sv.size());</div><div>#if _LIBCPP_DEBUG_LEVEL >= 2</div><div> __get_db()->__insert_c(this);</div><div>#endif</div><div>}</div></blockquote><div><br></div></div></div></blockquote><div><br></div></span><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><span class=""><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>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></span><div>No, because it can change the meaning of otherwise well defined code, as you pointed out initially. </div><div><div class="h5"><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 class="m_-7388923065028223553h5"><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_-7388923065028223553m_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 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"><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: <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/llvm-pr<wbr>oject/libcxx/trunk/include/str<wbr>ing?rev=276238&r1=276237&r2=27<wbr>6238&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>
#include <string><br>
#include <experimental/string_view><br>
using namespace std;<br>
using std::experimental::string_view<wbr>;<br>
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_-7388923065028223553m_8776782733827039247HOEnZb"><div class="m_-7388923065028223553m_8776782733827039247h5"><br>
> #include <iosfwd><br>
> #include <cstring><br>
> #include <cstdio> // For EOF.<br>
<br>
</div></div></blockquote></div><br></div>
</div></blockquote></div><br></div></div></div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div>