Actually I want to title my email "The string_ref overloads break
unified initialization", since I found that with an argument overloaded
for `string const&` and `string_ref`, you can no longer write

  foo({ "stri\0ng", 7 });

Since the implicit conversion is ambiguous.  However, the ""s suffix
can solve 80% cases of this use (string with embedded NULs).  But
to create a basic_string just for sizing a string literal is an obvious
overhead.

BTW, what is the best practice for new APIs using string_ref?
From my point of view, one single `basic_string_ref` without
`char const*` or `basic_string<...> const&` overloads is the best
choice, but it seems to be "inconsistent" (literally, not logically)
with the standard before `string_ref`.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

------=_Part_2093_7818122.1358876992108
Content-Type: text/plain; charset=ISO-8859-1

Op dinsdag 22 januari 2013 17:09:28 UTC+1 schreef Zhihao Yuan het volgende:

> Actually I want to title my email "The string_ref overloads break
> unified initialization", since I found that with an argument overloaded
> for `string const&` and `string_ref`, you can no longer write
>
>   foo({ "stri\0ng", 7 });
>
> Since the implicit conversion is ambiguous.  However, the ""s suffix
> can solve 80% cases of this use (string with embedded NULs).  But
> to create a basic_string just for sizing a string literal is an obvious
> overhead.
>

Why don't you remove the const string& overload?


--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



------=_Part_2093_7818122.1358876992108
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Op dinsdag 22 januari 2013 17:09:28 UTC+1 schreef Zhihao Yuan het volgende:=
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;">Actually I want to title m=
y email "The string_ref overloads break
<br>unified initialization", since I found that with an argument overloaded
<br>for `string const&amp;` and `string_ref`, you can no longer write
<br>
<br>&nbsp; foo({ "stri\0ng", 7 });
<br>
<br>Since the implicit conversion is ambiguous. &nbsp;However, the ""s suff=
ix
<br>can solve 80% cases of this use (string with embedded NULs). &nbsp;But
<br>to create a basic_string just for sizing a string literal is an obvious
<br>overhead.
<br></blockquote><div><br></div><div>Why don't you remove the const string&=
amp; overload?</div><div>&nbsp;</div><div><br></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_2093_7818122.1358876992108--

.

On Tue, Jan 22, 2013 at 11:49 AM, Olaf van der Spek
<olafvdspek@gmail.com> wrote:
> Why don't you remove the const string& overload?

The "string_ref" proposal only adds the `string_ref` overloads to the
existing APIs, not replacing `string const&`.  For new APIs, yes,
replacing `string const&`, or even `char const *`, should be considered,
and I'm asking whether such a practice should be  (unwritten)
established.


--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.

On Tue, Jan 22, 2013 at 8:09 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> Actually I want to title my email "The string_ref overloads break
> unified initialization", since I found that with an argument overloaded
> for `string const&` and `string_ref`, you can no longer write
>
>   foo({ "stri\0ng", 7 });
>
> Since the implicit conversion is ambiguous.

Argh. Thank you for pointing that out. :( I'll add it to the next
version of the paper so the LWG knows to consciously decide between
breaking this, breaking classes with an implicit conversion to
std::string, or failing to provide string_ref overloads in the obvious
places.

> However, the ""s suffix
> can solve 80% cases of this use (string with embedded NULs).  But
> to create a basic_string just for sizing a string literal is an obvious
> overhead.

Right.

> BTW, what is the best practice for new APIs using string_ref?
> From my point of view, one single `basic_string_ref` without
> `char const*` or `basic_string<...> const&` overloads is the best
> choice, but it seems to be "inconsistent" (literally, not logically)
> with the standard before `string_ref`.

IMO, a single basic_string_ref overload is best. The LWG also wanted
char const* overloads where the function could plausibly return
without calculating the length of the argument.

Jeffrey

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.



.