------=_Part_845_6798091.1366890344600
Content-Type: text/plain; charset=ISO-8859-1

Hi,

What happened to the string_view proposal in Bristol?

--

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



------=_Part_845_6798091.1366890344600
Content-Type: text/html; charset=ISO-8859-1

<div>Hi,</div><div><br></div>What happened to the string_view proposal in Bristol?

<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 unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_845_6798091.1366890344600--

.

------=_Part_503_11926481.1366891049429
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, April 25, 2013 12:45:44 PM UTC+1, Olaf van der Spek wrote:
>
> Hi,
>
> What happened to the string_view proposal in Bristol?


LEWG voted against including it in C++14,it was forwarded to LWG with a TS
as the target.

IMHO it started as a nice, simple proposal then ballooned into a monster as
everyone piled in their favourite feature and it ended up trying to add new
members to the already bloated std::string class.  Way to stall a proposal.

In any case, maybe that will give us time to change the name back to
string_ref *because everyone who has invented this type has named it some
variation on string_ref*. Noone I've spoken to likes the name string_view.


--

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



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

<br><br>On Thursday, April 25, 2013 12:45:44 PM UTC+1, Olaf van der Spek wr=
ote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Hi,</div><div><br></d=
iv>What happened to the string_view proposal in Bristol?</blockquote><div><=
br>LEWG voted against including it in C++14,it was forwarded to LWG with a =
TS as the target.<br><br>IMHO it started as a nice, simple proposal then ba=
llooned into a monster
 as everyone piled in their favourite feature and it ended up trying to=20
add new members to the already bloated std::string class.&nbsp; Way to stal=
l a proposal.<br><br>In any case, maybe that will give us time to change th=
e name back to string_ref <b>because everyone who has invented this type ha=
s named it some variation on string_ref</b>. Noone I've spoken to likes the=
 name string_view.<br><br><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 unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.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_503_11926481.1366891049429--

.

--089e013a0a1efb840804db2e3599
Content-Type: text/plain; charset=ISO-8859-1

On 25 April 2013 14:57, Jonathan Wakely <cxx@kayari.org> wrote:

> IMHO it started as a nice, simple proposal then ballooned into a monster
> as everyone piled in their favourite feature and it ended up trying to add
> new members to the already bloated std::string class.  Way to stall a
> proposal.
>
>

Preposterous! Such a thing never, never I say, happens in WG21! :P

--

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



--089e013a0a1efb840804db2e3599
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 25 April 2013 14:57, Jonathan Wakely <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:cxx@kayari.org" target=3D"_blank">cxx@kayari.org</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">IMHO it started as a nice, simple proposal t=
hen ballooned into a monster
 as everyone piled in their favourite feature and it ended up trying to=20
add new members to the already bloated std::string class.=A0 Way to stall a=
 proposal.<br><div><br></div></blockquote><div><br><br></div><div>Preposter=
ous! Such a thing never, never I say, happens in WG21! :P<br></div></div>
<br></div></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 unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.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 />

--089e013a0a1efb840804db2e3599--

.

On Thu, Apr 25, 2013 at 1:57 PM, Jonathan Wakely <cxx@kayari.org> wrote:
> IMHO it started as a nice, simple proposal then ballooned into a monster as
> everyone piled in their favourite feature and it ended up trying to add new
> members to the already bloated std::string class.  Way to stall a proposal.

Why wasn't it split into two proposals? One with the string_ref core
and one with all the pet peeves?

--

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



.

On Thu, Apr 25, 2013 at 4:57 AM, Jonathan Wakely <cxx@kayari.org> wrote:
>
>
> On Thursday, April 25, 2013 12:45:44 PM UTC+1, Olaf van der Spek wrote:
>>
>> Hi,
>>
>> What happened to the string_view proposal in Bristol?
>
>
> LEWG voted against including it in C++14,it was forwarded to LWG with a TS
> as the target.
>
> IMHO it started as a nice, simple proposal then ballooned into a monster as
> everyone piled in their favourite feature and it ended up trying to add new
> members to the already bloated std::string class.  Way to stall a proposal.

I don't think that's how it happened. The first version of the paper
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html#gensection-8),
presented in Kona, included very nearly the same set of members,
including all 4 new ones. In Portland, someone (STL?) argued that the
find() methods should accept const char* for optimization, and the
room agreed. Portland also suggested that there was a chance, although
only a chance, of getting it into C++14, in which case it needed to
update the rest of the standard, and since the room in Portland had
been sympathetic to the starts_with and ends_with members on both
string_ref and string, I included them there. Bristol then insisted
(5/4/1/2/0) that if it's at all compatible with string, it needs to be
completely compatible, so we'll get all the 'pos' and 'n' overloads in
the next mailing, and possibly copy() (4/2/2/3/2), but it's still the
same set of methods, and we're dropping starts_with and ends_with.

Even without that change, the paper in Bristol isn't necessarily right
for a TS: it needs to separate the string_view pieces from the changes
to the rest of the standard, in case LWG isn't comfortable including
rest-of-standard changes in a TS.

In Chicago, we will need people saying "it's good enough; put it in
the TS draft and iterate from there" for both this and other papers,
but I don't think the lack of that is why string_view isn't in a TS
yet.

> In any case, maybe that will give us time to change the name back to
> string_ref because everyone who has invented this type has named it some
> variation on string_ref. Noone I've spoken to likes the name string_view.

Beman suggested it, and there was an entire mailing
(http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3512.html#bikeshed)
when the paper suggested that the bikeshed was likely to converge on
string_view. Nobody spoke up in favor of string_ref. If you want to
participate in the bikeshed, you at least have to mention your
preferred color before it's painted. It is straightforward to change
back in Chicago, but it's going to take consensus, not just a
majority, and I don't want to waste time discussing it.

Jeffrey

--

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



.

On Thu, Apr 25, 2013 at 8:51 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> I don't think the lack of that is why string_view isn't in a TS
> yet.

FWIW, the real reasons are probably that I got conscripted to co-chair
LEWG and so didn't have time to update any papers during the week, and
that LWG was focusing on C++14, so once LEWG rejected string_view for
'14, it didn't have a chance to get looked at this meeting.

--

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



.

------=_Part_738_20387474.1366906919099
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, April 25, 2013 8:53:26 AM UTC-7, Jeffrey Yasskin wrote:
>
> On Thu, Apr 25, 2013 at 8:51 AM, Jeffrey Yasskin <jyas...@google.com<javascript:>>
> wrote:
> > I don't think the lack of that is why string_view isn't in a TS
> > yet.
>
> FWIW, the real reasons are probably that I got conscripted to co-chair
> LEWG and so didn't have time to update any papers during the week, and
> that LWG was focusing on C++14, so once LEWG rejected string_view for
> '14, it didn't have a chance to get looked at this meeting.
>

Which TS are we talking about? It's not clear to me what it is that
string_view missed being in yet. I know there's been some discussion for
various TS's for C++ library components, but those were generally about
specific functionality (networking, threading, filesystem, etc).

--

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



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

On Thursday, April 25, 2013 8:53:26 AM UTC-7, Jeffrey Yasskin wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Thu, Apr 25, 2013 at 8:51 AM, Jeff=
rey Yasskin &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"rHot3w8ORYMJ">jyas...@google.com</a>&gt; wrote:
<br>&gt; I don't think the lack of that is why string_view isn't in a TS
<br>&gt; yet.
<br>
<br>FWIW, the real reasons are probably that I got conscripted to co-chair
<br>LEWG and so didn't have time to update any papers during the week, and
<br>that LWG was focusing on C++14, so once LEWG rejected string_view for
<br>'14, it didn't have a chance to get looked at this meeting.
<br></blockquote><div><br>Which TS are we talking about? It's not clear to =
me what it is that string_view missed being in yet. I know there's been som=
e discussion for various TS's for C++ library components, but those were ge=
nerally about specific functionality (networking, threading, filesystem, et=
c).<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 unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.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_738_20387474.1366906919099--

.

------=_Part_531_18135244.1366910108989
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, April 25, 2013 4:51:19 PM UTC+1, Jeffrey Yasskin wrote:
>
> On Thu, Apr 25, 2013 at 4:57 AM, Jonathan Wakely <c...@kayari.org<javascript:>>
> wrote:
> >
> >
> > On Thursday, April 25, 2013 12:45:44 PM UTC+1, Olaf van der Spek wrote:
> >>
> >> Hi,
> >>
> >> What happened to the string_view proposal in Bristol?
> >
> >
> > LEWG voted against including it in C++14,it was forwarded to LWG with a
> TS
> > as the target.
> >
> > IMHO it started as a nice, simple proposal then ballooned into a monster
> as
> > everyone piled in their favourite feature and it ended up trying to add
> new
> > members to the already bloated std::string class.  Way to stall a
> proposal.
>
> I don't think that's how it happened. The first version of the paper
> (
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3334.html#gensection-8),
>
> presented in Kona, included very nearly the same set of members,
> including all 4 new ones. In Portland, someone (STL?) argued that the
> find() methods should accept const char* for optimization, and the
> room agreed. Portland also suggested that there was a chance, although
> only a chance, of getting it into C++14, in which case it needed to
> update the rest of the standard, and since the room in Portland had
> been sympathetic to the starts_with and ends_with members on both
> string_ref and string, I included them there. Bristol then insisted
> (5/4/1/2/0) that if it's at all compatible with string, it needs to be
> completely compatible, so we'll get all the 'pos' and 'n' overloads in
> the next mailing, and possibly copy() (4/2/2/3/2), but it's still the
> same set of methods, and we're dropping starts_with and ends_with.
>

Thanks for the corrections, I wasn't there for any of that so should have
kept my ill-informed opinions to myself :-)

--

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



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

<br><br>On Thursday, April 25, 2013 4:51:19 PM UTC+1, Jeffrey Yasskin wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Apr 25, 2013 at 4:57 =
AM, Jonathan Wakely &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfus=
cated-mailto=3D"6prX7pqStRsJ">c...@kayari.org</a>&gt; wrote:
<br>&gt;
<br>&gt;
<br>&gt; On Thursday, April 25, 2013 12:45:44 PM UTC+1, Olaf van der Spek w=
rote:
<br>&gt;&gt;
<br>&gt;&gt; Hi,
<br>&gt;&gt;
<br>&gt;&gt; What happened to the string_view proposal in Bristol?
<br>&gt;
<br>&gt;
<br>&gt; LEWG voted against including it in C++14,it was forwarded to LWG w=
ith a TS
<br>&gt; as the target.
<br>&gt;
<br>&gt; IMHO it started as a nice, simple proposal then ballooned into a m=
onster as
<br>&gt; everyone piled in their favourite feature and it ended up trying t=
o add new
<br>&gt; members to the already bloated std::string class. &nbsp;Way to sta=
ll a proposal.
<br>
<br>I don't think that's how it happened. The first version of the paper
<br>(<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n33=
34.html#gensection-8" target=3D"_blank">http://www.open-std.org/jtc1/<wbr>s=
c22/wg21/docs/papers/2012/<wbr>n3334.html#gensection-8</a>),
<br>presented in Kona, included very nearly the same set of members,
<br>including all 4 new ones. In Portland, someone (STL?) argued that the
<br>find() methods should accept const char* for optimization, and the
<br>room agreed. Portland also suggested that there was a chance, although
<br>only a chance, of getting it into C++14, in which case it needed to
<br>update the rest of the standard, and since the room in Portland had
<br>been sympathetic to the starts_with and ends_with members on both
<br>string_ref and string, I included them there. Bristol then insisted
<br>(5/4/1/2/0) that if it's at all compatible with string, it needs to be
<br>completely compatible, so we'll get all the 'pos' and 'n' overloads in
<br>the next mailing, and possibly copy() (4/2/2/3/2), but it's still the
<br>same set of methods, and we're dropping starts_with and ends_with.
<br></blockquote><div><br>Thanks for the corrections, I wasn't there for an=
y of that so should have kept my ill-informed opinions to myself :-)<br></d=
iv><br>

<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 unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.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_531_18135244.1366910108989--

.

On 4/25/13, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
> On 25 April 2013 14:57, Jonathan Wakely <cxx@kayari.org> wrote:
> > IMHO it started as a nice, simple proposal then ballooned into
> > a monster as everyone piled in their favourite feature and
> > it ended up trying to add new members to the already bloated
> > std::string class.  Way to stall a proposal.
>
> Preposterous! Such a thing never, never I say, happens in WG21! :P

You keep using that word.  I do not think it means what you think
it means.  :-)

My poster child is N2233, where it happened twice.  The feature
creep was more like an avalanche.

--
Lawrence Crowl

--

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



.

On Fri, Apr 26, 2013 at 2:02 AM, Lawrence Crowl <crowl@googlers.com> wrote:
>> Preposterous! Such a thing never, never I say, happens in WG21! :P
>
> You keep using that word.  I do not think it means what you think
> it means.  :-)
>
> My poster child is N2233, where it happened twice.  The feature
> creep was more like an avalanche.

What happened to that proposal?
--
Olaf

--

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



.

On Thu, Apr 25, 2013 at 12:21 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, April 25, 2013 8:53:26 AM UTC-7, Jeffrey Yasskin wrote:
>>
>> On Thu, Apr 25, 2013 at 8:51 AM, Jeffrey Yasskin <jyas...@google.com>
>> wrote:
>> > I don't think the lack of that is why string_view isn't in a TS
>> > yet.
>>
>> FWIW, the real reasons are probably that I got conscripted to co-chair
>> LEWG and so didn't have time to update any papers during the week, and
>> that LWG was focusing on C++14, so once LEWG rejected string_view for
>> '14, it didn't have a chance to get looked at this meeting.
>
>
> Which TS are we talking about? It's not clear to me what it is that
> string_view missed being in yet. I know there's been some discussion for
> various TS's for C++ library components, but those were generally about
> specific functionality (networking, threading, filesystem, etc).

There will be a general library TS for components that don't fit in
one of the specific functionality TSs. Tentatively to be finished late
2014.

--Beman

--

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



.

On Thu, Apr 25, 2013 at 11:53 AM, Jeffrey Yasskin <jyasskin@google.com> wrote:
> FWIW, the real reasons are probably that I got conscripted to co-chair
> LEWG and so didn't have time to update any papers during the week, and
> that LWG was focusing on C++14, so once LEWG rejected string_view for
> '14, it didn't have a chance to get looked at this meeting.

That was my fault. I had to skip the meeting at the last minute.
Jeffrey and Alan Talbot kindly stepped in as LEWG co-chairs, and by
all reports did a great job. But that meant they didn't have time to
turn around updates to their own papers during the meeting.

Thanks, Jeffrey and Alan!

--Beman

--

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



.

------=_Part_514_1462745119.1456261424161
Content-Type: multipart/alternative;
 boundary="----=_Part_515_1125111368.1456261424161"

------=_Part_515_1125111368.1456261424161
Content-Type: text/plain; charset=UTF-8

On Thursday, April 25, 2013 at 1:45:44 PM UTC+2, Olaf van der Spek wrote:
>
> Hi,
>
> What happened to the string_view proposal in Bristol?


I hate to sound like a broken record but could I ask for the status again?
I'd hate for it not to be in C++17..

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90aa729e-e9b7-436f-abe5-ed856f0fd561%40isocpp.org.

------=_Part_515_1125111368.1456261424161
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, April 25, 2013 at 1:45:44 PM UTC+2, Olaf van =
der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Hi,</div><=
div><br></div>What happened to the string_view proposal in Bristol?</blockq=
uote><div><br></div><div>I hate to sound like a broken record but could I a=
sk for the status again?</div><div>I&#39;d hate for it not to be in C++17..=
=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/90aa729e-e9b7-436f-abe5-ed856f0fd561%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/90aa729e-e9b7-436f-abe5-ed856f0fd561=
%40isocpp.org</a>.<br />

------=_Part_515_1125111368.1456261424161--
------=_Part_514_1462745119.1456261424161--

.

It's covered in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r0.html.

On Tue, Feb 23, 2016 at 1:03 PM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> On Thursday, April 25, 2013 at 1:45:44 PM UTC+2, Olaf van der Spek wrote:
>>
>> Hi,
>>
>> What happened to the string_view proposal in Bristol?
>
>
> I hate to sound like a broken record but could I ask for the status again?
> I'd hate for it not to be in C++17..
>
> --
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit
> https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/90aa729e-e9b7-436f-abe5-ed856f0fd561%40isocpp.org.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DL%2B%3DRuewhuL68rEBOhEYvg-LQf-zWenF2gGWd3Qb2bng%40mail.gmail.com.

.

------=_Part_11124_529058839.1456275543740
Content-Type: multipart/alternative;
 boundary="----=_Part_11125_1357253259.1456275543740"

------=_Part_11125_1357253259.1456275543740
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 23, 2016 at 4:04:56 PM UTC-5, Jeffrey Yasskin wrote:
>
> It's covered in
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r0.html.
>

I wouldn't say that it this entirely covers it. `string_view` has
competition <http://wg21.link/P0123>, and it would be silly if we got two
classes that do basically the same thing.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/477b147e-f082-4ccd-b286-0c174f02321d%40isocpp.org.

------=_Part_11125_1357253259.1456275543740
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 23, 2016 at 4:04:56 PM UTC-5, Jeffrey=
 Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">It&#39;s covere=
d in
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p022=
0r0.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0220r0.html\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGP9rufY_Ox80_eybdZ8bB7wX5jw&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0220r0.html\46sa\75D\46sntz\0751\46=
usg\75AFQjCNHGP9rufY_Ox80_eybdZ8bB7wX5jw&#39;;return true;">http://www.open=
-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0220r0.html</a>.
<br></blockquote><div><br>I wouldn&#39;t say that it this entirely covers i=
t. `string_view` <a href=3D"http://wg21.link/P0123">has competition</a>, an=
d it would be silly if we got two classes that do basically the same thing.=
</div><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/477b147e-f082-4ccd-b286-0c174f02321d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/477b147e-f082-4ccd-b286-0c174f02321d=
%40isocpp.org</a>.<br />

------=_Part_11125_1357253259.1456275543740--
------=_Part_11124_529058839.1456275543740--

.

--001a11425f30a7b669052c79ab1d
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 24, 2016 at 1:59 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, February 23, 2016 at 4:04:56 PM UTC-5, Jeffrey Yasskin wrote:
>>
>> It's covered in
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r0.html.
>>
>
> I wouldn't say that it this entirely covers it. `string_view` has
> competition <http://wg21.link/P0123>, and it would be silly if we got two
> classes that do basically the same thing.
>

"basic_string_span is presented as complementary type to the
basic_string_view of N3762 [1]. Each fulfills an important but different
aim."

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKiaUtHe5A1yYDHp0qPRHBHg1q46sf7JQ4DjnJCyhKFzQ%40mail.gmail.com.

--001a11425f30a7b669052c79ab1d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Feb 24, 2016 at 1:59 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bo=
rder-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">O=
n Tuesday, February 23, 2016 at 4:04:56 PM UTC-5, Jeffrey Yasskin wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padd=
ing-left:1ex">It&#39;s covered in
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p022=
0r0.html" rel=3D"nofollow" target=3D"_blank">http://www.open-std.org/jtc1/s=
c22/wg21/docs/papers/2016/p0220r0.html</a>.
<br></blockquote></span><div><br>I wouldn&#39;t say that it this entirely c=
overs it. `string_view` <a href=3D"http://wg21.link/P0123" target=3D"_blank=
">has competition</a>, and it would be silly if we got two classes that do =
basically the same thing.</div></div></blockquote><div><br></div><div>&quot=
;basic_string_span is presented as complementary type to the basic_string_v=
iew of N3762 [1]. Each
fulfills an important but different aim.&quot;</div><div>=C2=A0</div></div>=
<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKiaUtHe5A1yYDHp0qPRHBHg1q46s=
f7JQ4DjnJCyhKFzQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAB%2B4KHKiaUtH=
e5A1yYDHp0qPRHBHg1q46sf7JQ4DjnJCyhKFzQ%40mail.gmail.com</a>.<br />

--001a11425f30a7b669052c79ab1d--

.

------=_Part_11430_1496097592.1456278510130
Content-Type: multipart/alternative;
 boundary="----=_Part_11431_404415885.1456278510130"

------=_Part_11431_404415885.1456278510130
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 23, 2016 at 8:06:10 PM UTC-5, Andrew Tomazos wrote:
>
> On Wed, Feb 24, 2016 at 1:59 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Tuesday, February 23, 2016 at 4:04:56 PM UTC-5, Jeffrey Yasskin wrote:
>>>
>>> It's covered in
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r0.html.
>>>
>>
>> I wouldn't say that it this entirely covers it. `string_view` has
>> competition <http://wg21.link/P0123>, and it would be silly if we got
>> two classes that do basically the same thing.
>>
>
> "basic_string_span is presented as complementary type to the
> basic_string_view of N3762 [1]. Each fulfills an important but different
> aim."
>

Please read the rest of that paragraph. The substantive differences between
them are minimal at best. A `cstring_span` is functionally identical to a
`string_view`, with the minor exception of having fewer convenience APIs.
The whole thing amounts to nothing more than a fig leaf, a shabby pretense
that the *massive* similarities between the types are not so massive.

I mean, just look at that part about `string_view` having "support for
null-termination". This statement is so obviously wrong that it seems like
the author wrote it out of desperation, looking for *some* way to pretend
that similar things aren't similar. For the record, `string_view` has
exactly as much support for null-termination as `cstring_span` does.
Namely, the ability to be constructed from a `CharT*` array that is
null-terminated. And even that is supported via `char_traits<>::length`, *exactly
like `string_span`*'s constructor. Nothing else in `string_view` expects or
requires null termination; string_view::data() has this note:

> Unlike basic_string::data() and string literals, data() may return a
pointer to a buffer that is not null-terminated.

How exactly is that "support for null-termination"?

C++ doesn't need a distinction between "a sequence of constant characters
with `basic_string`'s API" and "a sequence of possibly-constant
characters". We need a *single* type that we can build APIs around that are
container-neutral, and having two virtually identical classes would not
help in this regard. It would be *absurd* for the committee to have both in
the language (not that I would put absurdity past the standard's committee).

But to be honest, I really don't think Neil MacIntosh is going to be
fooling anybody with that statement...

Personally, I say to take the best of both worlds. Retain `string_span`s
ability to be non-const, while taking `string_view`s API niceties.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5bf5ca4e-c38d-4e75-abd0-7181708d73b7%40isocpp.org.

------=_Part_11431_404415885.1456278510130
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 23, 2016 at 8:06:10 PM UTC-5, Andrew =
Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Wed, Feb 24, 2016 at 1:59 AM, Nicol Bol=
as <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"LyHLdXMgAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D=
&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:=
&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex"><div dir=3D"ltr"><span>On Tuesday, February 23, 2016 at 4:04:56 PM UTC=
-5, Jeffrey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">It&#39;s covered in
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p022=
0r0.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#3=
9;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22=
%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0220r0.html\46sa\75D\46sntz\0751\46usg\75=
AFQjCNHGP9rufY_Ox80_eybdZ8bB7wX5jw&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0220r0.html\46sa\75D\46sntz\0751\46=
usg\75AFQjCNHGP9rufY_Ox80_eybdZ8bB7wX5jw&#39;;return true;">http://www.open=
-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0220r0.html</a>.
<br></blockquote></span><div><br>I wouldn&#39;t say that it this entirely c=
overs it. `string_view` <a href=3D"http://wg21.link/P0123" target=3D"_blank=
" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.google.com/ur=
l?q\75http%3A%2F%2Fwg21.link%2FP0123\46sa\75D\46sntz\0751\46usg\75AFQjCNGOA=
Cm7e4IxiCu0UGhO_4UZHOGAPw&#39;;return true;" onclick=3D"this.href=3D&#39;ht=
tp://www.google.com/url?q\75http%3A%2F%2Fwg21.link%2FP0123\46sa\75D\46sntz\=
0751\46usg\75AFQjCNGOACm7e4IxiCu0UGhO_4UZHOGAPw&#39;;return true;">has comp=
etition</a>, and it would be silly if we got two classes that do basically =
the same thing.</div></div></blockquote><div><br></div><div>&quot;basic_str=
ing_span is presented as complementary type to the basic_string_view of N37=
62 [1]. Each
fulfills an important but different aim.&quot;<br></div></div></div></div><=
/blockquote><div><br>Please read the rest of that paragraph. The substantiv=
e differences between them are minimal at best. A `cstring_span` is functio=
nally identical to a `string_view`, with the minor exception of having fewe=
r convenience APIs. The whole thing amounts to nothing more than a fig leaf=
, a shabby pretense that the <i>massive</i> similarities between the types =
are not so massive.<br><br>I mean, just look at that part about `string_vie=
w` having &quot;support for null-termination&quot;. This statement is so ob=
viously wrong that it seems like the author wrote it out of desperation, lo=
oking for <i>some</i> way to pretend that similar things aren&#39;t similar=
.. For the record, `string_view` has exactly as much support for null-termin=
ation as `cstring_span` does. Namely, the ability to be constructed from a =
`CharT*` array that is null-terminated. And even that is supported via `cha=
r_traits&lt;&gt;::length`, <i>exactly like `string_span`</i>&#39;s construc=
tor. Nothing else in `string_view` expects or requires null termination; st=
ring_view::data() has this note:<br><br>&gt;     Unlike <code>basic_string:=
:data()</code> and string literals,
      <code>data()</code> may return a pointer to a buffer that is not null=
-terminated.<br><br>How exactly is that &quot;support for null-termination&=
quot;?<br><br>C++ doesn&#39;t need a distinction between &quot;a sequence o=
f constant characters with `basic_string`&#39;s API&quot; and &quot;a seque=
nce of possibly-constant characters&quot;. We need a <i>single</i> type tha=
t we can build APIs around that are container-neutral, and having two virtu=
ally identical classes would not help in this regard. It would be <i>absurd=
</i> for the committee to have both in the language (not that I would put a=
bsurdity past the standard&#39;s committee).<br><br>But to be honest, I rea=
lly don&#39;t think Neil MacIntosh is going to be fooling anybody with that=
 statement...<br><br>Personally, I say to take the best of both worlds. Ret=
ain `string_span`s ability to be non-const, while taking `string_view`s API=
 niceties.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5bf5ca4e-c38d-4e75-abd0-7181708d73b7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5bf5ca4e-c38d-4e75-abd0-7181708d73b7=
%40isocpp.org</a>.<br />

------=_Part_11431_404415885.1456278510130--
------=_Part_11430_1496097592.1456278510130--

.

--001a1140ed3a2afae6052c7a4fcc
Content-Type: text/plain; charset=UTF-8

On Tue, Feb 23, 2016 at 5:48 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, February 23, 2016 at 8:06:10 PM UTC-5, Andrew Tomazos wrote:
>>
>> On Wed, Feb 24, 2016 at 1:59 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Tuesday, February 23, 2016 at 4:04:56 PM UTC-5, Jeffrey Yasskin wrote:
>>>>
>>>> It's covered in
>>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r0.html.
>>>>
>>>
>>> I wouldn't say that it this entirely covers it. `string_view` has
>>> competition <http://wg21.link/P0123>, and it would be silly if we got
>>> two classes that do basically the same thing.
>>>
>>
>> "basic_string_span is presented as complementary type to the
>> basic_string_view of N3762 [1]. Each fulfills an important but different
>> aim."
>>
>
> Please read the rest of that paragraph. The substantive differences
> between them are minimal at best. A `cstring_span` is functionally
> identical to a `string_view`, with the minor exception of having fewer
> convenience APIs. The whole thing amounts to nothing more than a fig leaf,
> a shabby pretense that the *massive* similarities between the types are
> not so massive.
>
> I mean, just look at that part about `string_view` having "support for
> null-termination". This statement is so obviously wrong that it seems like
> the author wrote it out of desperation, looking for *some* way to pretend
> that similar things aren't similar. For the record, `string_view` has
> exactly as much support for null-termination as `cstring_span` does.
> Namely, the ability to be constructed from a `CharT*` array that is
> null-terminated. And even that is supported via `char_traits<>::length`, *exactly
> like `string_span`*'s constructor. Nothing else in `string_view` expects
> or requires null termination; string_view::data() has this note:
>
> > Unlike basic_string::data() and string literals, data() may return a
> pointer to a buffer that is not null-terminated.
>
> How exactly is that "support for null-termination"?
>
> C++ doesn't need a distinction between "a sequence of constant characters
> with `basic_string`'s API" and "a sequence of possibly-constant
> characters". We need a *single* type that we can build APIs around that
> are container-neutral, and having two virtually identical classes would not
> help in this regard. It would be *absurd* for the committee to have both
> in the language (not that I would put absurdity past the standard's
> committee).
>
> But to be honest, I really don't think Neil MacIntosh is going to be
> fooling anybody with that statement...
>
> Personally, I say to take the best of both worlds. Retain `string_span`s
> ability to be non-const, while taking `string_view`s API niceties.
>

I'm definitely looking for use cases for modifying the data pointed to by a
string_view, where you're not equally well-served by a span<char>.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXk7svEJbs15JoavwRFtziYFropk30EcR4JLMd3rgFfbQw%40mail.gmail.com.

--001a1140ed3a2afae6052c7a4fcc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Feb 23, 2016 at 5:48 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank" class=3D"cremed">jmckesson@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">On Tuesday, February 23, 2016 at 8:06:10 PM UTC-5, Andrew Tomazos wrot=
e:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On Wed, Feb 24, 2016 at 1:59 AM, Nicol Bol=
as <span dir=3D"ltr">&lt;<a rel=3D"nofollow" class=3D"cremed">jmck...@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,=
204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><span>On Tu=
esday, February 23, 2016 at 4:04:56 PM UTC-5, Jeffrey Yasskin wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex">It&#39;s covered in
<br><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p022=
0r0.html" rel=3D"nofollow" target=3D"_blank" class=3D"cremed">http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2016/p0220r0.html</a>.
<br></blockquote></span><div><br>I wouldn&#39;t say that it this entirely c=
overs it. `string_view` <a href=3D"http://wg21.link/P0123" rel=3D"nofollow"=
 target=3D"_blank" class=3D"cremed">has competition</a>, and it would be si=
lly if we got two classes that do basically the same thing.</div></div></bl=
ockquote><div><br></div><div>&quot;basic_string_span is presented as comple=
mentary type to the basic_string_view of N3762 [1]. Each
fulfills an important but different aim.&quot;<br></div></div></div></div><=
/blockquote></span><div><br>Please read the rest of that paragraph. The sub=
stantive differences between them are minimal at best. A `cstring_span` is =
functionally identical to a `string_view`, with the minor exception of havi=
ng fewer convenience APIs. The whole thing amounts to nothing more than a f=
ig leaf, a shabby pretense that the <i>massive</i> similarities between the=
 types are not so massive.<br><br>I mean, just look at that part about `str=
ing_view` having &quot;support for null-termination&quot;. This statement i=
s so obviously wrong that it seems like the author wrote it out of desperat=
ion, looking for <i>some</i> way to pretend that similar things aren&#39;t =
similar. For the record, `string_view` has exactly as much support for null=
-termination as `cstring_span` does. Namely, the ability to be constructed =
from a `CharT*` array that is null-terminated. And even that is supported v=
ia `char_traits&lt;&gt;::length`, <i>exactly like `string_span`</i>&#39;s c=
onstructor. Nothing else in `string_view` expects or requires null terminat=
ion; string_view::data() has this note:<br><br>&gt;     Unlike <code>basic_=
string::data()</code> and string literals,
      <code>data()</code> may return a pointer to a buffer that is not null=
-terminated.<br><br>How exactly is that &quot;support for null-termination&=
quot;?<br><br>C++ doesn&#39;t need a distinction between &quot;a sequence o=
f constant characters with `basic_string`&#39;s API&quot; and &quot;a seque=
nce of possibly-constant characters&quot;. We need a <i>single</i> type tha=
t we can build APIs around that are container-neutral, and having two virtu=
ally identical classes would not help in this regard. It would be <i>absurd=
</i> for the committee to have both in the language (not that I would put a=
bsurdity past the standard&#39;s committee).<br><br>But to be honest, I rea=
lly don&#39;t think Neil MacIntosh is going to be fooling anybody with that=
 statement...<br><br>Personally, I say to take the best of both worlds. Ret=
ain `string_span`s ability to be non-const, while taking `string_view`s API=
 niceties.<br></div></div></blockquote><div><br></div><div>I&#39;m definite=
ly looking for use cases for modifying the data pointed to by a string_view=
, where you&#39;re not equally well-served by a span&lt;char&gt;.=C2=A0</di=
v></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXk7svEJbs15JoavwRFtziYFropk30Ec=
R4JLMd3rgFfbQw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXk7svEJbs15=
JoavwRFtziYFropk30EcR4JLMd3rgFfbQw%40mail.gmail.com</a>.<br />

--001a1140ed3a2afae6052c7a4fcc--

.

--047d7bd75c3a851e61052c7a704e
Content-Type: text/plain; charset=UTF-8

On Feb 23, 2016 7:51 PM, "'Jeffrey Yasskin' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:
>
> I'm definitely looking for use cases for modifying the data pointed to by
a string_view, where you're not equally well-served by a span<char>.
>

`buffer` in Network TS works for me.

--
Zhihao

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDMBSbbnxcLY2nojjbaW4B9C11mNsSgneRjoxF1PThD8A%40mail.gmail.com.

--047d7bd75c3a851e61052c7a704e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On Feb 23, 2016 7:51 PM, &quot;&#39;Jeffrey Yasskin&#39; via ISO C++ Standa=
rd - Future Proposals&quot; &lt;<a href=3D"mailto:std-proposals@isocpp.org"=
>std-proposals@isocpp.org</a>&gt; wrote:<br>
&gt;<br>
&gt; I&#39;m definitely looking for use cases for modifying the data pointe=
d to by a string_view, where you&#39;re not equally well-served by a span&l=
t;char&gt;.=C2=A0<br>
&gt;</p>
<p dir=3D"ltr">`buffer` in Network TS works for me.</p>
<p dir=3D"ltr">--<br>
Zhihao</p>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAGsORuDMBSbbnxcLY2nojjbaW4B9C11mNsSg=
neRjoxF1PThD8A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAGsORuDMBSbbnxcL=
Y2nojjbaW4B9C11mNsSgneRjoxF1PThD8A%40mail.gmail.com</a>.<br />

--047d7bd75c3a851e61052c7a704e--

.

------=_Part_207_1899316531.1456325079483
Content-Type: multipart/alternative;
 boundary="----=_Part_208_1762485097.1456325079484"

------=_Part_208_1762485097.1456325079484
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 23, 2016 at 8:51:50 PM UTC-5, Jeffrey Yasskin wrote:
>
> I'm definitely looking for use cases for modifying the data pointed to by
> a string_view, where you're not equally well-served by a span<char>.
>

You mean besides the very important semantic distinction between "this is
an array of bytes" and "this is a string"? A function that takes
`span<char>` is taking a byte array. A function that takes
`string_span<char>` could is taking a *string* and it will interpret its
bytes as such.

And no, a typedef isn't good enough.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1f0bc9e9-79a9-468a-bd66-080096a19861%40isocpp.org.

------=_Part_208_1762485097.1456325079484
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 23, 2016 at 8:51:50 PM UTC-5, Jeffrey=
 Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote"><div>I&#39;m definitely looking for use c=
ases for modifying the data pointed to by a string_view, where you&#39;re n=
ot equally well-served by a span&lt;char&gt;.</div></div></div></div></bloc=
kquote><div><br>You mean besides the very important semantic distinction be=
tween &quot;this is an array of bytes&quot; and &quot;this is a string&quot=
;? A function that takes `span&lt;char&gt;` is taking a byte array. A funct=
ion that takes `string_span&lt;char&gt;` could is taking a <i>string</i> an=
d it will interpret its bytes as such.<br><br>And no, a typedef isn&#39;t g=
ood enough.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/1f0bc9e9-79a9-468a-bd66-080096a19861%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/1f0bc9e9-79a9-468a-bd66-080096a19861=
%40isocpp.org</a>.<br />

------=_Part_208_1762485097.1456325079484--
------=_Part_207_1899316531.1456325079483--

.

2016-02-24 15:44 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:
> On Tuesday, February 23, 2016 at 8:51:50 PM UTC-5, Jeffrey Yasskin wrote:
>>
>> I'm definitely looking for use cases for modifying the data pointed to by
>> a string_view, where you're not equally well-served by a span<char>.
>
>
> You mean besides the very important semantic distinction between "this is an
> array of bytes" and "this is a string"? A function that takes `span<char>`
> is taking a byte array. A function that takes `string_span<char>` could is
> taking a string and it will interpret its bytes as such.
>
> And no, a typedef isn't good enough.

Shouldn't a byte array be span<unsigned char>?


--
Olaf

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7U3HNnLEjJwH9CKoN8aBid9svMrxZWV4_S1pAsMq4-bRG7WA%40mail.gmail.com.

.

On 24 February 2016 at 16:44, Nicol Bolas <jmckesson@gmail.com> wrote:
>> I'm definitely looking for use cases for modifying the data pointed to by
>> a string_view, where you're not equally well-served by a span<char>.
> You mean besides the very important semantic distinction between "this is an
> array of bytes" and "this is a string"? A function that takes `span<char>`
> is taking a byte array. A function that takes `string_span<char>` could is
> taking a string and it will interpret its bytes as such.

I don't quite follow what you mean by "taking a string and will
interpret its bytes as such".

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbejRStAXExRwfxVbrSNKfJbxJL0rFfYwRLe49DAf4EPA%40mail.gmail.com.

.

On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas wrote:
> You mean besides the very important semantic distinction between "this is
> an array of bytes" and "this is a string"? A function that takes
> `span<char>` is taking a byte array. A function that takes
> `string_span<char>` could is taking a *string* and it will interpret its
> bytes as such.

In Qt, QByteArray has a lot of string-related methods, like uppercasing/
lowercasing, number formatting, etc.

It's not worth having two classes if one is a superset of the other.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1904188.8axfEussFW%40tjmaciei-mobl4.

.

--001a1134b3ce8593cd052c878f2c
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <thiago@macieira.org>
wrote:

> On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas wrote:
> > You mean besides the very important semantic distinction between "this is
> > an array of bytes" and "this is a string"? A function that takes
> > `span<char>` is taking a byte array. A function that takes
> > `string_span<char>` could is taking a *string* and it will interpret its
> > bytes as such.
>
> In Qt, QByteArray has a lot of string-related methods, like uppercasing/
> lowercasing, number formatting, etc.
>

I'm sympathetic to having different types for "strings" and "byte arrays",
but basically nothing that mutates a "string" can work on un-owned data.
(QByteArray appears to own its data, so isn't so relevant.) Uppercasing,
for example, can need to reallocate because it can change the length of a
UTF-8 string.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DTQMSr%2BywDW3yoqq1mE5w5MabBWWyMFZ4%3DEemoHFpNRw%40mail.gmail.com.

--001a1134b3ce8593cd052c878f2c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank" class=3D"cremed">thiago@m=
acieira.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas=
 wrote:<br>
&gt; You mean besides the very important semantic distinction between &quot=
;this is<br>
&gt; an array of bytes&quot; and &quot;this is a string&quot;? A function t=
hat takes<br>
&gt; `span&lt;char&gt;` is taking a byte array. A function that takes<br>
</span>&gt; `string_span&lt;char&gt;` could is taking a *string* and it wil=
l interpret its<br>
&gt; bytes as such.<br>
<br>
In Qt, QByteArray has a lot of string-related methods, like uppercasing/<br=
>
lowercasing, number formatting, etc.<br></blockquote><div><br></div><div>I&=
#39;m sympathetic to having different types for &quot;strings&quot; and &qu=
ot;byte arrays&quot;, but basically nothing that mutates a &quot;string&quo=
t; can work on un-owned data. (QByteArray appears to own its data, so isn&#=
39;t so relevant.) Uppercasing, for example, can need to reallocate because=
 it can change the length of a UTF-8 string.</div><div><br></div><div>Jeffr=
ey</div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DTQMSr%2BywDW3yoqq1mE5w5MabB=
WWyMFZ4%3DEemoHFpNRw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dX%3DT=
QMSr%2BywDW3yoqq1mE5w5MabBWWyMFZ4%3DEemoHFpNRw%40mail.gmail.com</a>.<br />

--001a1134b3ce8593cd052c878f2c--

.

------=_Part_882_120165127.1456335808014
Content-Type: multipart/alternative;
 boundary="----=_Part_883_1035791742.1456335808021"

------=_Part_883_1035791742.1456335808021
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville Voutilainen
wrote:
>
> On 24 February 2016 at 16:44, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >> I'm definitely looking for use cases for modifying the data pointed to
> by
> >> a string_view, where you're not equally well-served by a span<char>.
> > You mean besides the very important semantic distinction between "this
> is an
> > array of bytes" and "this is a string"? A function that takes
> `span<char>`
> > is taking a byte array. A function that takes `string_span<char>` could
> is
> > taking a string and it will interpret its bytes as such.
>
> I don't quite follow what you mean by "taking a string and will
> interpret its bytes as such".
>

That it might do things with it that you do with strings, which are
distinct from actions you take with arbitrary byte arrays.

If you have a function that needs to take a string, we need the type system
to say that an arbitrary array of bytes is *not* appropriate. For example,
`filesystem::path` constructors should be able to take strings of various
encodings. But it should not be able to take `span<const char>`, since that
is semantically an array of bytes.

Let's say we want to have a version of `to_string` that allows you to write
the data directly into an existing string, rather than creating a string
for you. If it took `span<char>`, then all semantic information is lost;
that's just an array of bytes. If it took `string_span<char>`, then you
know that it's writing to a contiguous string array.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bc409340-6438-4643-8c37-c7e55687d3c5%40isocpp.org.

------=_Part_883_1035791742.1456335808021
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville=
 Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 Febru=
ary 2016 at 16:44, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"nc6RoKpNAgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;j=
avascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt;&gt; I&#39;m definitely looking for use cases for modifying the dat=
a pointed to by
<br>&gt;&gt; a string_view, where you&#39;re not equally well-served by a s=
pan&lt;char&gt;.
<br>&gt; You mean besides the very important semantic distinction between &=
quot;this is an
<br>&gt; array of bytes&quot; and &quot;this is a string&quot;? A function =
that takes `span&lt;char&gt;`
<br>&gt; is taking a byte array. A function that takes `string_span&lt;char=
&gt;` could is
<br>&gt; taking a string and it will interpret its bytes as such.
<br>
<br>I don&#39;t quite follow what you mean by &quot;taking a string and wil=
l
<br>interpret its bytes as such&quot;.
<br></blockquote><div><br>That it might do things with it that you do with =
strings, which are distinct from actions you take with arbitrary byte array=
s.<br><br>If you have a function that needs to take a string, we need the t=
ype system to say that an arbitrary array of bytes is <i>not</i> appropriat=
e. For example, `filesystem::path` constructors should be able to take stri=
ngs of various encodings. But it should not be able to take `span&lt;const =
char&gt;`, since that is semantically an array of bytes.<br><br>Let&#39;s s=
ay we want to have a version of `to_string` that allows you to write the da=
ta directly into an existing string, rather than creating a string for you.=
 If it took `span&lt;char&gt;`, then all semantic information is lost; that=
&#39;s just an array of bytes. If it took `string_span&lt;char&gt;`, then y=
ou know that it&#39;s writing to a contiguous string array.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bc409340-6438-4643-8c37-c7e55687d3c5%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bc409340-6438-4643-8c37-c7e55687d3c5=
%40isocpp.org</a>.<br />

------=_Part_883_1035791742.1456335808021--
------=_Part_882_120165127.1456335808014--

.

------=_Part_565_1228182917.1456336237738
Content-Type: multipart/alternative;
 boundary="----=_Part_566_502453630.1456336237739"

------=_Part_566_502453630.1456336237739
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin wrote:
>
> On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas wrote:
>> > You mean besides the very important semantic distinction between "this
>> is
>> > an array of bytes" and "this is a string"? A function that takes
>> > `span<char>` is taking a byte array. A function that takes
>> > `string_span<char>` could is taking a *string* and it will interpret its
>> > bytes as such.
>>
>> In Qt, QByteArray has a lot of string-related methods, like uppercasing/
>> lowercasing, number formatting, etc.
>>
>
> I'm sympathetic to having different types for "strings" and "byte arrays",
> but basically nothing that mutates a "string" can work on un-owned data.
> (QByteArray appears to own its data, so isn't so relevant.) Uppercasing,
> for example, can need to reallocate because it can change the length of a
> UTF-8 string.
>

You assume that string mutation is the only non-const operation that is
important. Consider integer-to-string conversions. Currently, our only
options for these are the C-APIs that take a pointer+size, or C++ APIs that
allocate std::strings for us (which incidentally don't even allow us to use
allocators). Filling an existing allocation with string data is an
important operation, one which `string_view` cannot actually do, and which
`span<char>` has the wrong meaning.

Do we really want people to do this:

string str(50);
to_string(span<char>(str), some_integer);

Or do we want people to be able to do this:

string str(50);
to_string(str, some_integer); //Implicit conversion from string.

Or do you think that `basic_string` should have an implicit conversion to
"array of bytes", which looses semantic information?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f8d89ab1-1181-49f1-99e6-09909584c4c9%40isocpp.org.

------=_Part_566_502453630.1456336237739
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, February 24, 2016 at 12:40:35 PM UTC-5, Jeff=
rey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">On Wed, Feb 24, 2016 at 9:27 AM, Thiag=
o Macieira <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"imkEMrdWAgAJ" rel=3D"nofollow" onmousedown=3D"this=
..href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;jav=
ascript:&#39;;return true;">thi...@macieira.org</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex"><span>On quarta-feira, 24 de fevereiro de 2016=
 06:44:39 PST Nicol Bolas wrote:<br>
&gt; You mean besides the very important semantic distinction between &quot=
;this is<br>
&gt; an array of bytes&quot; and &quot;this is a string&quot;? A function t=
hat takes<br>
&gt; `span&lt;char&gt;` is taking a byte array. A function that takes<br>
</span>&gt; `string_span&lt;char&gt;` could is taking a *string* and it wil=
l interpret its<br>
&gt; bytes as such.<br>
<br>
In Qt, QByteArray has a lot of string-related methods, like uppercasing/<br=
>
lowercasing, number formatting, etc.<br></blockquote><div><br></div><div>I&=
#39;m sympathetic to having different types for &quot;strings&quot; and &qu=
ot;byte arrays&quot;, but basically nothing that mutates a &quot;string&quo=
t; can work on un-owned data. (QByteArray appears to own its data, so isn&#=
39;t so relevant.) Uppercasing, for example, can need to reallocate because=
 it can change the length of a UTF-8 string.<br></div></div></div></div></b=
lockquote><div><br>You assume that string mutation is the only non-const op=
eration that is important. Consider integer-to-string conversions. Currentl=
y, our only options for these are the C-APIs that take a pointer+size, or C=
++ APIs that allocate std::strings for us (which incidentally don&#39;t eve=
n allow us to use allocators). Filling an existing allocation with string d=
ata is an important operation, one which `string_view` cannot actually do, =
and which `span&lt;char&gt;` has the wrong meaning.<br><br>Do we really wan=
t people to do this:<br><br><div class=3D"prettyprint" style=3D"background-=
color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: =
solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprin=
t"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">string</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> str</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify">50<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">to_string</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><code class=3D"prettyprint"><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">span</span><span style=
=3D"color: #080;" class=3D"styled-by-prettify">&lt;char&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">(</span></code>str</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> some_integer</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></div><=
br>Or do we want people to be able to do this:<br><br><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187,=
 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">string</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> str</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=
=3D"styled-by-prettify">50</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>to_string</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">str</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> some_integer<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">//Implicit conversion from s=
tring.</span></div></code></div><br>Or do you think that `basic_string` sho=
uld have an implicit conversion to &quot;array of bytes&quot;, which looses=
 semantic information?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f8d89ab1-1181-49f1-99e6-09909584c4c9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f8d89ab1-1181-49f1-99e6-09909584c4c9=
%40isocpp.org</a>.<br />

------=_Part_566_502453630.1456336237739--
------=_Part_565_1228182917.1456336237738--

.

--001a1140fe22a87bc4052c87e72b
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 24, 2016 at 9:50 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin
> wrote:
>>
>> On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <thi...@macieira.org>
>> wrote:
>>
>>> On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas wrote:
>>> > You mean besides the very important semantic distinction between "this
>>> is
>>> > an array of bytes" and "this is a string"? A function that takes
>>> > `span<char>` is taking a byte array. A function that takes
>>> > `string_span<char>` could is taking a *string* and it will interpret
>>> its
>>> > bytes as such.
>>>
>>> In Qt, QByteArray has a lot of string-related methods, like uppercasing/
>>> lowercasing, number formatting, etc.
>>>
>>
>> I'm sympathetic to having different types for "strings" and "byte
>> arrays", but basically nothing that mutates a "string" can work on un-owned
>> data. (QByteArray appears to own its data, so isn't so relevant.)
>> Uppercasing, for example, can need to reallocate because it can change the
>> length of a UTF-8 string.
>>
>
> You assume that string mutation is the only non-const operation that is
> important. Consider integer-to-string conversions. Currently, our only
> options for these are the C-APIs that take a pointer+size, or C++ APIs that
> allocate std::strings for us (which incidentally don't even allow us to use
> allocators). Filling an existing allocation with string data is an
> important operation, one which `string_view` cannot actually do, and which
> `span<char>` has the wrong meaning.
>
> Do we really want people to do this:
>
> string str(50);
> to_string(span<char>(str), some_integer);
>
> Or do we want people to be able to do this:
>
> string str(50);
> to_string(str, some_integer); //Implicit conversion from string.
>
> Or do you think that `basic_string` should have an implicit conversion to
> "array of bytes", which looses semantic information?
>

Jens has a proposal for this, but it's based around ranges of characters:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html. The
core problem with serializing to an unowned range is that you have to track
how much space is available vs how much you've used. At that point, you're
not really representing a "string" anymore. You're representing a byte
array whose prefix is a string, and span<char> seems better suited for that.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmoihTrE536wkjvx69LLF6i1%3DNfOve1Da21a6hDPzXg_w%40mail.gmail.com.

--001a1140fe22a87bc4052c87e72b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Feb 24, 2016 at 9:50 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank" class=3D"cremed">jmckesson@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Wednes=
day, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin wrote:<span cl=
ass=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">=
On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a r=
el=3D"nofollow" class=3D"cremed">thi...@macieira.org</a>&gt;</span> wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:soli=
d;padding-left:1ex"><span>On quarta-feira, 24 de fevereiro de 2016 06:44:39=
 PST Nicol Bolas wrote:<br>
&gt; You mean besides the very important semantic distinction between &quot=
;this is<br>
&gt; an array of bytes&quot; and &quot;this is a string&quot;? A function t=
hat takes<br>
&gt; `span&lt;char&gt;` is taking a byte array. A function that takes<br>
</span>&gt; `string_span&lt;char&gt;` could is taking a *string* and it wil=
l interpret its<br>
&gt; bytes as such.<br>
<br>
In Qt, QByteArray has a lot of string-related methods, like uppercasing/<br=
>
lowercasing, number formatting, etc.<br></blockquote><div><br></div><div>I&=
#39;m sympathetic to having different types for &quot;strings&quot; and &qu=
ot;byte arrays&quot;, but basically nothing that mutates a &quot;string&quo=
t; can work on un-owned data. (QByteArray appears to own its data, so isn&#=
39;t so relevant.) Uppercasing, for example, can need to reallocate because=
 it can change the length of a UTF-8 string.<br></div></div></div></div></b=
lockquote></span><div><br>You assume that string mutation is the only non-c=
onst operation that is important. Consider integer-to-string conversions. C=
urrently, our only options for these are the C-APIs that take a pointer+siz=
e, or C++ APIs that allocate std::strings for us (which incidentally don&#3=
9;t even allow us to use allocators). Filling an existing allocation with s=
tring data is an important operation, one which `string_view` cannot actual=
ly do, and which `span&lt;char&gt;` has the wrong meaning.<br><br>Do we rea=
lly want people to do this:<br><br><div style=3D"border:1px solid rgb(187,1=
87,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div>=
<span style=3D"color:rgb(0,0,136)">string</span><span style=3D"color:rgb(0,=
0,0)"> str</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,102,102)">50</span><span style=3D"color:rgb(102,102,0)">);<=
/span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(=
0,0,0)">to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(0,0,0)">span</spa=
n><span style=3D"color:rgb(0,136,0)">&lt;char&gt;</span><span style=3D"colo=
r:rgb(0,0,0)">(</span></code>str</span><span style=3D"color:rgb(102,102,0)"=
>),</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=
=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></s=
pan></div></code></div><br>Or do we want people to be able to do this:<br><=
br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;bac=
kground-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136=
)">string</span><span style=3D"color:rgb(0,0,0)"> str</span><span style=3D"=
color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,102,102)">50</span=
><span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0=
,0)"><br>to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span=
 style=3D"color:rgb(0,0,0)">str</span><span style=3D"color:rgb(102,102,0)">=
,</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=3D=
"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(136,0,0)">//Implicit conversion from string.</span><=
/div></code></div><br>Or do you think that `basic_string` should have an im=
plicit conversion to &quot;array of bytes&quot;, which looses semantic info=
rmation?<br></div></div></blockquote><div></div></div><br></div><div class=
=3D"gmail_extra">Jens has a proposal for this, but it&#39;s based around ra=
nges of characters:=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2016/p0067r1.html">http://www.open-std.org/jtc1/sc22/wg21/docs/=
papers/2016/p0067r1.html</a>. The core problem with serializing to an unown=
ed range is that you have to track how much space is available vs how much =
you&#39;ve used. At that point, you&#39;re not really representing a &quot;=
string&quot; anymore. You&#39;re representing a byte array whose prefix is =
a string, and span&lt;char&gt; seems better suited for that.</div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Jeffrey</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXmoihTrE536wkjvx69LLF6i1%3DNfOv=
e1Da21a6hDPzXg_w%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmoihTrE5=
36wkjvx69LLF6i1%3DNfOve1Da21a6hDPzXg_w%40mail.gmail.com</a>.<br />

--001a1140fe22a87bc4052c87e72b--

.

On 02/24/2016 07:04 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future Pro=
posals wrote:
> Jens has a proposal for this, but it's based around ranges of characters:=
 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html. The =
core problem with serializing to an unowned range is that you have to track=
 how much space is available vs how much you've used. At that point, you're=
 not really representing a "string" anymore. You're representing a byte arr=
ay whose prefix is a string, and span<char> seems better suited for that.

Add-on point: A byte array should be represented by
span<unsigned char>, which is different from span<char>.

For example, you get guaranteed modulo 2^n arithmetic
from an unsigned char, which is sometimes useful.

In contrast, you should never do arithmetic on "char".

Jens

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/56CDF443.4050005%40gmx.net.

.

On 24 February 2016 at 19:43, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville Voutilainen
> wrote:
>>
>> On 24 February 2016 at 16:44, Nicol Bolas <jmck...@gmail.com> wrote:
>> >> I'm definitely looking for use cases for modifying the data pointed to
>> >> by
>> >> a string_view, where you're not equally well-served by a span<char>.
>> > You mean besides the very important semantic distinction between "this
>> > is an
>> > array of bytes" and "this is a string"? A function that takes
>> > `span<char>`
>> > is taking a byte array. A function that takes `string_span<char>` could
>> > is
>> > taking a string and it will interpret its bytes as such.
>>
>> I don't quite follow what you mean by "taking a string and will
>> interpret its bytes as such".
>
>
> That it might do things with it that you do with strings, which are distinct
> from actions you take with arbitrary byte arrays.

Well, neither string_view nor string_span guarantee that you're
dealing with a "string", whatever you
choose to mean by that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUaZ6v_C0vakjKqpntwkdfbCcML-An52f_ssOmRv-fXOqQ%40mail.gmail.com.

.

------=_Part_915_238138560.1456414892864
Content-Type: multipart/alternative;
 boundary="----=_Part_916_295089532.1456414892864"

------=_Part_916_295089532.1456414892864
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 24, 2016 at 2:10:18 PM UTC-5, Ville Voutilainen
wrote:
>
> On 24 February 2016 at 19:43, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville Voutilainen
> > wrote:
> >>
> >> On 24 February 2016 at 16:44, Nicol Bolas <jmck...@gmail.com> wrote:
> >> >> I'm definitely looking for use cases for modifying the data pointed
> to
> >> >> by
> >> >> a string_view, where you're not equally well-served by a span<char>.
> >> > You mean besides the very important semantic distinction between
> "this
> >> > is an
> >> > array of bytes" and "this is a string"? A function that takes
> >> > `span<char>`
> >> > is taking a byte array. A function that takes `string_span<char>`
> could
> >> > is
> >> > taking a string and it will interpret its bytes as such.
> >>
> >> I don't quite follow what you mean by "taking a string and will
> >> interpret its bytes as such".
> >
> >
> > That it might do things with it that you do with strings, which are
> distinct
> > from actions you take with arbitrary byte arrays.
>
> Well, neither string_view nor string_span guarantee that you're
> dealing with a "string", whatever you
> choose to mean by that.
>

.... I'm not sure what your point is.

If you have a class called "string_span", and you feel the need to fill it
with non-string data, C++ won't stop you. Just like if you have a
`basic_string`, and you feel the need to fill it with non-string data, C++
won't stop you.

C++ isn't a safe language.

But that doesn't mean that semantic meaning cannot/should not be expressed
by the type system. After all, that is *exactly* why people want strong
aliases; so that values which are technically `int` and `float` and so
forth can have actual semantic meanings to the type system. So that you
can't just pass a naked `float` to a function; you have to give it a
specific semantic meaning beyond `float`.

Having a string type that is semantically distinct from "array of bytes" is
a *good thing*.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a02492f4-144e-4027-bb54-35b94759dae0%40isocpp.org.

------=_Part_916_295089532.1456414892864
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, February 24, 2016 at 2:10:18 PM UTC-5, Ville=
 Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 24 Febru=
ary 2016 at 19:43, Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"5yqskpxbAgAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;j=
avascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrote:
<br>&gt; On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville Voutila=
inen
<br>&gt; wrote:
<br>&gt;&gt;
<br>&gt;&gt; On 24 February 2016 at 16:44, Nicol Bolas &lt;<a>jmck...@gmail=
..com</a>&gt; wrote:
<br>&gt;&gt; &gt;&gt; I&#39;m definitely looking for use cases for modifyin=
g the data pointed to
<br>&gt;&gt; &gt;&gt; by
<br>&gt;&gt; &gt;&gt; a string_view, where you&#39;re not equally well-serv=
ed by a span&lt;char&gt;.
<br>&gt;&gt; &gt; You mean besides the very important semantic distinction =
between &quot;this
<br>&gt;&gt; &gt; is an
<br>&gt;&gt; &gt; array of bytes&quot; and &quot;this is a string&quot;? A =
function that takes
<br>&gt;&gt; &gt; `span&lt;char&gt;`
<br>&gt;&gt; &gt; is taking a byte array. A function that takes `string_spa=
n&lt;char&gt;` could
<br>&gt;&gt; &gt; is
<br>&gt;&gt; &gt; taking a string and it will interpret its bytes as such.
<br>&gt;&gt;
<br>&gt;&gt; I don&#39;t quite follow what you mean by &quot;taking a strin=
g and will
<br>&gt;&gt; interpret its bytes as such&quot;.
<br>&gt;
<br>&gt;
<br>&gt; That it might do things with it that you do with strings, which ar=
e distinct
<br>&gt; from actions you take with arbitrary byte arrays.
<br>
<br>Well, neither string_view nor string_span guarantee that you&#39;re
<br>dealing with a &quot;string&quot;, whatever you
<br>choose to mean by that.
<br></blockquote><div><br>... I&#39;m not sure what your point is.<br><br>I=
f you have a class called &quot;string_span&quot;, and you feel the need to=
 fill it with non-string data, C++ won&#39;t stop you. Just like if you hav=
e a `basic_string`, and you feel the need to fill it with non-string data, =
C++ won&#39;t stop you.<br><br>C++ isn&#39;t a safe language.<br><br>But th=
at doesn&#39;t mean that semantic meaning cannot/should not be expressed by=
 the type system. After all, that is <i>exactly</i> why people want strong =
aliases; so that values which are technically `int` and `float` and so fort=
h can have actual semantic meanings to the type system. So that you can&#39=
;t just pass a naked `float` to a function; you have to give it a specific =
semantic meaning beyond `float`.<br><br>Having a string type that is semant=
ically distinct from &quot;array of bytes&quot; is a <i>good thing</i>.<br>=
</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a02492f4-144e-4027-bb54-35b94759dae0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a02492f4-144e-4027-bb54-35b94759dae0=
%40isocpp.org</a>.<br />

------=_Part_916_295089532.1456414892864--
------=_Part_915_238138560.1456414892864--

.

On 25 February 2016 at 17:41, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, February 24, 2016 at 2:10:18 PM UTC-5, Ville Voutilainen
> wrote:
>>
>> On 24 February 2016 at 19:43, Nicol Bolas <jmck...@gmail.com> wrote:
>> > On Wednesday, February 24, 2016 at 9:54:45 AM UTC-5, Ville Voutilainen
>> > wrote:
>> >>
>> >> On 24 February 2016 at 16:44, Nicol Bolas <jmck...@gmail.com> wrote:
>> >> >> I'm definitely looking for use cases for modifying the data pointed
>> >> >> to
>> >> >> by
>> >> >> a string_view, where you're not equally well-served by a span<char>.
>> >> > You mean besides the very important semantic distinction between
>> >> > "this
>> >> > is an
>> >> > array of bytes" and "this is a string"? A function that takes
>> >> > `span<char>`
>> >> > is taking a byte array. A function that takes `string_span<char>`
>> >> > could
>> >> > is
>> >> > taking a string and it will interpret its bytes as such.
>> >>
>> >> I don't quite follow what you mean by "taking a string and will
>> >> interpret its bytes as such".
>> >
>> >
>> > That it might do things with it that you do with strings, which are
>> > distinct
>> > from actions you take with arbitrary byte arrays.
>>
>> Well, neither string_view nor string_span guarantee that you're
>> dealing with a "string", whatever you
>> choose to mean by that.
>
>
> ... I'm not sure what your point is.

You wrote " A function that takes `string_span<char>` is taking a
string and it will interpret its bytes as such."
That's certainly not the case with the proposed string_span, because
it doesn't guarantee that it stores a "string".

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUbbNQT2Epasyw8AzFJT_P5x1Zdt194%2BBja9D5tWH8bH7g%40mail.gmail.com.

.

------=_Part_567_41246059.1456415110060
Content-Type: multipart/alternative;
 boundary="----=_Part_568_1710234001.1456415110060"

------=_Part_568_1710234001.1456415110060
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 24, 2016 at 1:05:04 PM UTC-5, Jeffrey Yasskin wrote:
>
> On Wed, Feb 24, 2016 at 9:50 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Wednesday, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin
>> wrote:
>>>
>>> On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <thi...@macieira.org>
>>> wrote:
>>>
>>>> On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas wrote:
>>>> > You mean besides the very important semantic distinction between
>>>> "this is
>>>> > an array of bytes" and "this is a string"? A function that takes
>>>> > `span<char>` is taking a byte array. A function that takes
>>>> > `string_span<char>` could is taking a *string* and it will interpret
>>>> its
>>>> > bytes as such.
>>>>
>>>> In Qt, QByteArray has a lot of string-related methods, like uppercasing/
>>>> lowercasing, number formatting, etc.
>>>>
>>>
>>> I'm sympathetic to having different types for "strings" and "byte
>>> arrays", but basically nothing that mutates a "string" can work on un-owned
>>> data. (QByteArray appears to own its data, so isn't so relevant.)
>>> Uppercasing, for example, can need to reallocate because it can change the
>>> length of a UTF-8 string.
>>>
>>
>> You assume that string mutation is the only non-const operation that is
>> important. Consider integer-to-string conversions. Currently, our only
>> options for these are the C-APIs that take a pointer+size, or C++ APIs that
>> allocate std::strings for us (which incidentally don't even allow us to use
>> allocators). Filling an existing allocation with string data is an
>> important operation, one which `string_view` cannot actually do, and which
>> `span<char>` has the wrong meaning.
>>
>> Do we really want people to do this:
>>
>> string str(50);
>> to_string(span<char>(str), some_integer);
>>
>> Or do we want people to be able to do this:
>>
>> string str(50);
>> to_string(str, some_integer); //Implicit conversion from string.
>>
>> Or do you think that `basic_string` should have an implicit conversion to
>> "array of bytes", which looses semantic information?
>>
>
> Jens has a proposal for this, but it's based around ranges of characters:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html. The
> core problem with serializing to an unowned range is that you have to track
> how much space is available vs how much you've used. At that point, you're
> not really representing a "string" anymore. You're representing a byte
> array whose prefix is a string, and span<char> seems better suited for that.
>

Let's say that I accept the idea that the unowned range isn't technically a
string yet (even though `basic_string` lets you make strings of
value-initialized CharT's of arbitrary length). Regardless of that, the
return value would most assuredly be a real, honest-to-God string. It would
be a `string_span` of the appropriate range within the given range of
characters passed in.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/e4d72a34-ffed-4414-a55c-8065fda36cc8%40isocpp.org.

------=_Part_568_1710234001.1456415110060
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, February 24, 2016 at 1:05:04 PM UTC-5, Jeffr=
ey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Wed, Feb 24, 2016 at 9:50 AM, Nicol =
Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"RcL4Wg1YAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-widt=
h:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-le=
ft:1ex"><div dir=3D"ltr">On Wednesday, February 24, 2016 at 12:40:35 PM UTC=
-5, Jeffrey Yasskin wrote:<span><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,20=
4,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote">On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <sp=
an dir=3D"ltr">&lt;<a rel=3D"nofollow">thi...@macieira.org</a>&gt;</span> w=
rote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><span>On quarta-feira, 24 de fevereiro de 2016 06=
:44:39 PST Nicol Bolas wrote:<br>
&gt; You mean besides the very important semantic distinction between &quot=
;this is<br>
&gt; an array of bytes&quot; and &quot;this is a string&quot;? A function t=
hat takes<br>
&gt; `span&lt;char&gt;` is taking a byte array. A function that takes<br>
</span>&gt; `string_span&lt;char&gt;` could is taking a *string* and it wil=
l interpret its<br>
&gt; bytes as such.<br>
<br>
In Qt, QByteArray has a lot of string-related methods, like uppercasing/<br=
>
lowercasing, number formatting, etc.<br></blockquote><div><br></div><div>I&=
#39;m sympathetic to having different types for &quot;strings&quot; and &qu=
ot;byte arrays&quot;, but basically nothing that mutates a &quot;string&quo=
t; can work on un-owned data. (QByteArray appears to own its data, so isn&#=
39;t so relevant.) Uppercasing, for example, can need to reallocate because=
 it can change the length of a UTF-8 string.<br></div></div></div></div></b=
lockquote></span><div><br>You assume that string mutation is the only non-c=
onst operation that is important. Consider integer-to-string conversions. C=
urrently, our only options for these are the C-APIs that take a pointer+siz=
e, or C++ APIs that allocate std::strings for us (which incidentally don&#3=
9;t even allow us to use allocators). Filling an existing allocation with s=
tring data is an important operation, one which `string_view` cannot actual=
ly do, and which `span&lt;char&gt;` has the wrong meaning.<br><br>Do we rea=
lly want people to do this:<br><br><div style=3D"border:1px solid rgb(187,1=
87,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div>=
<span style=3D"color:rgb(0,0,136)">string</span><span style=3D"color:rgb(0,=
0,0)"> str</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,102,102)">50</span><span style=3D"color:rgb(102,102,0)">);<=
/span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(=
0,0,0)">to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(0,0,0)">span</spa=
n><span style=3D"color:rgb(0,136,0)">&lt;char&gt;</span><span style=3D"colo=
r:rgb(0,0,0)">(</span></code>str</span><span style=3D"color:rgb(102,102,0)"=
>),</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=
=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></s=
pan></div></code></div><br>Or do we want people to be able to do this:<br><=
br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;bac=
kground-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136=
)">string</span><span style=3D"color:rgb(0,0,0)"> str</span><span style=3D"=
color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,102,102)">50</span=
><span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0=
,0)"><br>to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span=
 style=3D"color:rgb(0,0,0)">str</span><span style=3D"color:rgb(102,102,0)">=
,</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=3D=
"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(136,0,0)">//Implicit conversion from string.</span><=
/div></code></div><br>Or do you think that `basic_string` should have an im=
plicit conversion to &quot;array of bytes&quot;, which looses semantic info=
rmation?<br></div></div></blockquote><div></div></div><br></div><div>Jens h=
as a proposal for this, but it&#39;s based around ranges of characters:=C2=
=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067=
r1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0067r1.html\46sa\75D\46sntz\0751\46usg\75A=
FQjCNFN0t-UUEzs6iFgmKCDYMBnC2_zXA&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0067r1.html\46sa\75D\46sntz\0751\46=
usg\75AFQjCNFN0t-UUEzs6iFgmKCDYMBnC2_zXA&#39;;return true;">http://www.open=
-<wbr>std.org/jtc1/sc22/wg21/docs/<wbr>papers/2016/p0067r1.html</a>. The co=
re problem with serializing to an unowned range is that you have to track h=
ow much space is available vs how much you&#39;ve used. At that point, you&=
#39;re not really representing a &quot;string&quot; anymore. You&#39;re rep=
resenting a byte array whose prefix is a string, and span&lt;char&gt; seems=
 better suited for that.</div></div></blockquote><div><br>Let&#39;s say tha=
t I accept the idea that the unowned range isn&#39;t technically a string y=
et (even though `basic_string` lets you make strings of value-initialized C=
harT&#39;s of arbitrary length). Regardless of that, the return value would=
 most assuredly be a real, honest-to-God string. It would be a `string_span=
` of the appropriate range within the given range of characters passed in.<=
br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/e4d72a34-ffed-4414-a55c-8065fda36cc8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e4d72a34-ffed-4414-a55c-8065fda36cc8=
%40isocpp.org</a>.<br />

------=_Part_568_1710234001.1456415110060--
------=_Part_567_41246059.1456415110060--

.

------=_Part_888_929284830.1456415229308
Content-Type: multipart/alternative;
 boundary="----=_Part_889_67628094.1456415229308"

------=_Part_889_67628094.1456415229308
Content-Type: text/plain; charset=UTF-8

On Wednesday, February 24, 2016 at 1:19:51 PM UTC-5, Jens Maurer wrote:
>
> On 02/24/2016 07:04 PM, 'Jeffrey Yasskin' via ISO C++ Standard - Future
> Proposals wrote:
> > Jens has a proposal for this, but it's based around ranges of
> characters:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html. The
> core problem with serializing to an unowned range is that you have to track
> how much space is available vs how much you've used. At that point, you're
> not really representing a "string" anymore. You're representing a byte
> array whose prefix is a string, and span<char> seems better suited for
> that.
>
> Add-on point: A byte array should be represented by
> span<unsigned char>, which is different from span<char>.
>
> For example, you get guaranteed modulo 2^n arithmetic
> from an unsigned char, which is sometimes useful.
>
> In contrast, you should never do arithmetic on "char".
>
> Jens
>

Now you're just digging yourself deeper. The reason being that `unsigned
char` can also mean `UTF-8 code unit`. So is a `span<unsigned char>` an
array of bytes or a UTF-8-encoded string?

Of course, if we had a proper `char8_t` type, we wouldn't have to ask that
question and we could cheerfully relegate `unsigned char` to mean "byte".
But no, the committee in its infinite wisdom decided against that.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/302278aa-6f1c-4aea-995e-964528a05afd%40isocpp.org.

------=_Part_889_67628094.1456415229308
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, February 24, 2016 at 1:19:51 PM UTC-5, Jens =
Maurer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 02/24/2016 07:=
04 PM, &#39;Jeffrey Yasskin&#39; via ISO C++ Standard - Future Proposals wr=
ote:
<br>&gt; Jens has a proposal for this, but it&#39;s based around ranges of =
characters: <a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2=
016/p0067r1.html" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc=
1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0067r1.html\46sa\75D\46sntz\0751\=
46usg\75AFQjCNFN0t-UUEzs6iFgmKCDYMBnC2_zXA&#39;;return true;" onclick=3D"th=
is.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%=
2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0067r1.html\46sa\75D\46sntz\=
0751\46usg\75AFQjCNFN0t-UUEzs6iFgmKCDYMBnC2_zXA&#39;;return true;">http://w=
ww.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2016/<wbr>p0067r1.html</a>.=
 The core problem with serializing to an unowned range is that you have to =
track how much space is available vs how much you&#39;ve used. At that poin=
t, you&#39;re not really representing a &quot;string&quot; anymore. You&#39=
;re representing a byte array whose prefix is a string, and span&lt;char&gt=
; seems better suited for that.
<br>
<br>Add-on point: A byte array should be represented by
<br>span&lt;unsigned char&gt;, which is different from span&lt;char&gt;.
<br>
<br>For example, you get guaranteed modulo 2^n arithmetic
<br>from an unsigned char, which is sometimes useful.
<br>
<br>In contrast, you should never do arithmetic on &quot;char&quot;.
<br>
<br>Jens
<br></blockquote><div><br>Now you&#39;re just digging yourself deeper. The =
reason being that `unsigned char` can also mean `UTF-8 code unit`. So is a =
`span&lt;unsigned char&gt;` an array of bytes or a UTF-8-encoded string?<br=
><br>Of course, if we had a proper `char8_t` type, we wouldn&#39;t have to =
ask that question and we could cheerfully relegate `unsigned char` to mean =
&quot;byte&quot;. But no, the committee in its infinite wisdom decided agai=
nst that.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/302278aa-6f1c-4aea-995e-964528a05afd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/302278aa-6f1c-4aea-995e-964528a05afd=
%40isocpp.org</a>.<br />

------=_Part_889_67628094.1456415229308--
------=_Part_888_929284830.1456415229308--

.

--001a1140ed3af62283052c9a1fbc
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 25, 2016 at 7:45 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, February 24, 2016 at 1:05:04 PM UTC-5, Jeffrey Yasskin wrote:
>>
>> On Wed, Feb 24, 2016 at 9:50 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>> On Wednesday, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin
>>> wrote:
>>>>
>>>> On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <thi...@macieira.org>
>>>> wrote:
>>>>
>>>>> On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas
>>>>> wrote:
>>>>> > You mean besides the very important semantic distinction between
>>>>> "this is
>>>>> > an array of bytes" and "this is a string"? A function that takes
>>>>> > `span<char>` is taking a byte array. A function that takes
>>>>> > `string_span<char>` could is taking a *string* and it will interpret
>>>>> its
>>>>> > bytes as such.
>>>>>
>>>>> In Qt, QByteArray has a lot of string-related methods, like
>>>>> uppercasing/
>>>>> lowercasing, number formatting, etc.
>>>>>
>>>>
>>>> I'm sympathetic to having different types for "strings" and "byte
>>>> arrays", but basically nothing that mutates a "string" can work on un-owned
>>>> data. (QByteArray appears to own its data, so isn't so relevant.)
>>>> Uppercasing, for example, can need to reallocate because it can change the
>>>> length of a UTF-8 string.
>>>>
>>>
>>> You assume that string mutation is the only non-const operation that is
>>> important. Consider integer-to-string conversions. Currently, our only
>>> options for these are the C-APIs that take a pointer+size, or C++ APIs that
>>> allocate std::strings for us (which incidentally don't even allow us to use
>>> allocators). Filling an existing allocation with string data is an
>>> important operation, one which `string_view` cannot actually do, and which
>>> `span<char>` has the wrong meaning.
>>>
>>> Do we really want people to do this:
>>>
>>> string str(50);
>>> to_string(span<char>(str), some_integer);
>>>
>>> Or do we want people to be able to do this:
>>>
>>> string str(50);
>>> to_string(str, some_integer); //Implicit conversion from string.
>>>
>>> Or do you think that `basic_string` should have an implicit conversion
>>> to "array of bytes", which looses semantic information?
>>>
>>
>> Jens has a proposal for this, but it's based around ranges of characters:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html.
>> The core problem with serializing to an unowned range is that you have to
>> track how much space is available vs how much you've used. At that point,
>> you're not really representing a "string" anymore. You're representing a
>> byte array whose prefix is a string, and span<char> seems better suited for
>> that.
>>
>
> Let's say that I accept the idea that the unowned range isn't technically
> a string yet (even though `basic_string` lets you make strings of
> value-initialized CharT's of arbitrary length). Regardless of that, the
> return value would most assuredly be a real, honest-to-God string. It would
> be a `string_span` of the appropriate range within the given range of
> characters passed in.
>
> Could you be more precise? I see an in/out parameter in your signature,
not a return value. Clearly the in/out parameter can't change types across
the call. It'd be totally fine to return a string_view the refers to a
sub-range of the input span<char>, and that works with the current types.

Jeffrey

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmJYbHkwciJAQ10xRsVqv1wBDL1uJHFGWnWFbiyVFEDtA%40mail.gmail.com.

--001a1140ed3af62283052c9a1fbc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Feb 25, 2016 at 7:45 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank" class=3D"cremed">jmckesson@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"=
ltr">On Wednesday, February 24, 2016 at 1:05:04 PM UTC-5, Jeffrey Yasskin w=
rote:<span class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Wed, Feb 24, 2016 at 9:50 AM, Nicol =
Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow" class=3D"cremed">jmck...@gm=
ail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,2=
04,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">On Wedne=
sday, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin wrote:<span><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Fe=
b 24, 2016 at 9:27 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a rel=3D"nofo=
llow" class=3D"cremed">thi...@macieira.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-wi=
dth:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-=
left:1ex"><span>On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol=
 Bolas wrote:<br>
&gt; You mean besides the very important semantic distinction between &quot=
;this is<br>
&gt; an array of bytes&quot; and &quot;this is a string&quot;? A function t=
hat takes<br>
&gt; `span&lt;char&gt;` is taking a byte array. A function that takes<br>
</span>&gt; `string_span&lt;char&gt;` could is taking a *string* and it wil=
l interpret its<br>
&gt; bytes as such.<br>
<br>
In Qt, QByteArray has a lot of string-related methods, like uppercasing/<br=
>
lowercasing, number formatting, etc.<br></blockquote><div><br></div><div>I&=
#39;m sympathetic to having different types for &quot;strings&quot; and &qu=
ot;byte arrays&quot;, but basically nothing that mutates a &quot;string&quo=
t; can work on un-owned data. (QByteArray appears to own its data, so isn&#=
39;t so relevant.) Uppercasing, for example, can need to reallocate because=
 it can change the length of a UTF-8 string.<br></div></div></div></div></b=
lockquote></span><div><br>You assume that string mutation is the only non-c=
onst operation that is important. Consider integer-to-string conversions. C=
urrently, our only options for these are the C-APIs that take a pointer+siz=
e, or C++ APIs that allocate std::strings for us (which incidentally don&#3=
9;t even allow us to use allocators). Filling an existing allocation with s=
tring data is an important operation, one which `string_view` cannot actual=
ly do, and which `span&lt;char&gt;` has the wrong meaning.<br><br>Do we rea=
lly want people to do this:<br><br><div style=3D"border:1px solid rgb(187,1=
87,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div>=
<span style=3D"color:rgb(0,0,136)">string</span><span style=3D"color:rgb(0,=
0,0)"> str</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,102,102)">50</span><span style=3D"color:rgb(102,102,0)">);<=
/span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(=
0,0,0)">to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(0,0,0)">span</spa=
n><span style=3D"color:rgb(0,136,0)">&lt;char&gt;</span><span style=3D"colo=
r:rgb(0,0,0)">(</span></code>str</span><span style=3D"color:rgb(102,102,0)"=
>),</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=
=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></s=
pan></div></code></div><br>Or do we want people to be able to do this:<br><=
br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;bac=
kground-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136=
)">string</span><span style=3D"color:rgb(0,0,0)"> str</span><span style=3D"=
color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,102,102)">50</span=
><span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0=
,0)"><br>to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span=
 style=3D"color:rgb(0,0,0)">str</span><span style=3D"color:rgb(102,102,0)">=
,</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=3D=
"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(136,0,0)">//Implicit conversion from string.</span><=
/div></code></div><br>Or do you think that `basic_string` should have an im=
plicit conversion to &quot;array of bytes&quot;, which looses semantic info=
rmation?<br></div></div></blockquote><div></div></div><br></div><div>Jens h=
as a proposal for this, but it&#39;s based around ranges of characters:=C2=
=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067=
r1.html" rel=3D"nofollow" target=3D"_blank" class=3D"cremed">http://www.ope=
n-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html</a>. The core proble=
m with serializing to an unowned range is that you have to track how much s=
pace is available vs how much you&#39;ve used. At that point, you&#39;re no=
t really representing a &quot;string&quot; anymore. You&#39;re representing=
 a byte array whose prefix is a string, and span&lt;char&gt; seems better s=
uited for that.</div></div></blockquote></span><div><br>Let&#39;s say that =
I accept the idea that the unowned range isn&#39;t technically a string yet=
 (even though `basic_string` lets you make strings of value-initialized Cha=
rT&#39;s of arbitrary length). Regardless of that, the return value would m=
ost assuredly be a real, honest-to-God string. It would be a `string_span` =
of the appropriate range within the given range of characters passed in.<br=
></div></div><span class=3D"">

<p></p>

</span></blockquote><div></div></div></div><div class=3D"gmail_extra">Could=
 you be more precise? I see an in/out parameter in your signature, not a re=
turn value. Clearly the in/out parameter can&#39;t change types across the =
call. It&#39;d be totally fine to return a string_view the refers to a sub-=
range of the input span&lt;char&gt;, and that works with the current types.=
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Jeffr=
ey</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CANh-dXmJYbHkwciJAQ10xRsVqv1wBDL1uJHF=
GWnWFbiyVFEDtA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh-dXmJYbHkwciJ=
AQ10xRsVqv1wBDL1uJHFGWnWFbiyVFEDtA%40mail.gmail.com</a>.<br />

--001a1140ed3af62283052c9a1fbc--

.

------=_Part_15_1485122172.1456453648419
Content-Type: multipart/alternative;
 boundary="----=_Part_16_710131461.1456453648424"

------=_Part_16_710131461.1456453648424
Content-Type: text/plain; charset=UTF-8

On Thursday, February 25, 2016 at 10:49:18 AM UTC-5, Jeffrey Yasskin wrote:
>
> On Thu, Feb 25, 2016 at 7:45 AM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Wednesday, February 24, 2016 at 1:05:04 PM UTC-5, Jeffrey Yasskin
>> wrote:
>>>
>>> On Wed, Feb 24, 2016 at 9:50 AM, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>> On Wednesday, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin
>>>> wrote:
>>>>>
>>>>> On Wed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <thi...@macieira.org>
>>>>> wrote:
>>>>>
>>>>>> On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas
>>>>>> wrote:
>>>>>> > You mean besides the very important semantic distinction between
>>>>>> "this is
>>>>>> > an array of bytes" and "this is a string"? A function that takes
>>>>>> > `span<char>` is taking a byte array. A function that takes
>>>>>> > `string_span<char>` could is taking a *string* and it will
>>>>>> interpret its
>>>>>> > bytes as such.
>>>>>>
>>>>>> In Qt, QByteArray has a lot of string-related methods, like
>>>>>> uppercasing/
>>>>>> lowercasing, number formatting, etc.
>>>>>>
>>>>>
>>>>> I'm sympathetic to having different types for "strings" and "byte
>>>>> arrays", but basically nothing that mutates a "string" can work on un-owned
>>>>> data. (QByteArray appears to own its data, so isn't so relevant.)
>>>>> Uppercasing, for example, can need to reallocate because it can change the
>>>>> length of a UTF-8 string.
>>>>>
>>>>
>>>> You assume that string mutation is the only non-const operation that is
>>>> important. Consider integer-to-string conversions. Currently, our only
>>>> options for these are the C-APIs that take a pointer+size, or C++ APIs that
>>>> allocate std::strings for us (which incidentally don't even allow us to use
>>>> allocators). Filling an existing allocation with string data is an
>>>> important operation, one which `string_view` cannot actually do, and which
>>>> `span<char>` has the wrong meaning.
>>>>
>>>> Do we really want people to do this:
>>>>
>>>> string str(50);
>>>> to_string(span<char>(str), some_integer);
>>>>
>>>> Or do we want people to be able to do this:
>>>>
>>>> string str(50);
>>>> to_string(str, some_integer); //Implicit conversion from string.
>>>>
>>>> Or do you think that `basic_string` should have an implicit conversion
>>>> to "array of bytes", which looses semantic information?
>>>>
>>>
>>> Jens has a proposal for this, but it's based around ranges of
>>> characters:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067r1.html.
>>> The core problem with serializing to an unowned range is that you have to
>>> track how much space is available vs how much you've used. At that point,
>>> you're not really representing a "string" anymore. You're representing a
>>> byte array whose prefix is a string, and span<char> seems better suited for
>>> that.
>>>
>>
>> Let's say that I accept the idea that the unowned range isn't technically
>> a string yet (even though `basic_string` lets you make strings of
>> value-initialized CharT's of arbitrary length). Regardless of that, the
>> return value would most assuredly be a real, honest-to-God string. It would
>> be a `string_span` of the appropriate range within the given range of
>> characters passed in.
>>
>> Could you be more precise? I see an in/out parameter in your signature,
> not a return value. Clearly the in/out parameter can't change types across
> the call. It'd be totally fine to return a string_view the refers to a
> sub-range of the input span<char>, and that works with the current types.
>

It would not be "totally fine" because the return value is `const`. You're
not merely referring to a subrange of another range, but to a completely
different type of range.

It'd be like passing a `vector<T>&` to someone, and them returning a
`span<const T>` into the vector. It makes no sense.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b5c72de8-d6d6-4be7-a352-3151dc42546e%40isocpp.org.

------=_Part_16_710131461.1456453648424
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 25, 2016 at 10:49:18 AM UTC-5, Jeffr=
ey Yasskin wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote">On Thu, Feb 25, 2016 at 7:45 AM, Nicol =
Bolas <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"7De-HzmfAgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, February 24, 2016 at 1=
:05:04 PM UTC-5, Jeffrey Yasskin wrote:<span><blockquote class=3D"gmail_quo=
te" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-=
left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Wed, Feb 24, =
2016 at 9:50 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck=
....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"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 dir=3D"ltr">On=
 Wednesday, February 24, 2016 at 12:40:35 PM UTC-5, Jeffrey Yasskin wrote:<=
span><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:so=
lid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On W=
ed, Feb 24, 2016 at 9:27 AM, Thiago Macieira <span dir=3D"ltr">&lt;<a rel=
=3D"nofollow">thi...@macieira.org</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;b=
order-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"=
><span>On quarta-feira, 24 de fevereiro de 2016 06:44:39 PST Nicol Bolas wr=
ote:<br>
&gt; You mean besides the very important semantic distinction between &quot=
;this is<br>
&gt; an array of bytes&quot; and &quot;this is a string&quot;? A function t=
hat takes<br>
&gt; `span&lt;char&gt;` is taking a byte array. A function that takes<br>
</span>&gt; `string_span&lt;char&gt;` could is taking a *string* and it wil=
l interpret its<br>
&gt; bytes as such.<br>
<br>
In Qt, QByteArray has a lot of string-related methods, like uppercasing/<br=
>
lowercasing, number formatting, etc.<br></blockquote><div><br></div><div>I&=
#39;m sympathetic to having different types for &quot;strings&quot; and &qu=
ot;byte arrays&quot;, but basically nothing that mutates a &quot;string&quo=
t; can work on un-owned data. (QByteArray appears to own its data, so isn&#=
39;t so relevant.) Uppercasing, for example, can need to reallocate because=
 it can change the length of a UTF-8 string.<br></div></div></div></div></b=
lockquote></span><div><br>You assume that string mutation is the only non-c=
onst operation that is important. Consider integer-to-string conversions. C=
urrently, our only options for these are the C-APIs that take a pointer+siz=
e, or C++ APIs that allocate std::strings for us (which incidentally don&#3=
9;t even allow us to use allocators). Filling an existing allocation with s=
tring data is an important operation, one which `string_view` cannot actual=
ly do, and which `span&lt;char&gt;` has the wrong meaning.<br><br>Do we rea=
lly want people to do this:<br><br><div style=3D"border:1px solid rgb(187,1=
87,187);word-wrap:break-word;background-color:rgb(250,250,250)"><code><div>=
<span style=3D"color:rgb(0,0,136)">string</span><span style=3D"color:rgb(0,=
0,0)"> str</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,102,102)">50</span><span style=3D"color:rgb(102,102,0)">);<=
/span><span style=3D"color:rgb(0,0,0)"><br></span><span style=3D"color:rgb(=
0,0,0)">to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span =
style=3D"color:rgb(0,0,0)"><code><span style=3D"color:rgb(0,0,0)">span</spa=
n><span style=3D"color:rgb(0,136,0)">&lt;char&gt;</span><span style=3D"colo=
r:rgb(0,0,0)">(</span></code>str</span><span style=3D"color:rgb(102,102,0)"=
>),</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=
=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"><br></s=
pan></div></code></div><br>Or do we want people to be able to do this:<br><=
br><div style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;bac=
kground-color:rgb(250,250,250)"><code><div><span style=3D"color:rgb(0,0,136=
)">string</span><span style=3D"color:rgb(0,0,0)"> str</span><span style=3D"=
color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0,102,102)">50</span=
><span style=3D"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0=
,0)"><br>to_string</span><span style=3D"color:rgb(102,102,0)">(</span><span=
 style=3D"color:rgb(0,0,0)">str</span><span style=3D"color:rgb(102,102,0)">=
,</span><span style=3D"color:rgb(0,0,0)"> some_integer</span><span style=3D=
"color:rgb(102,102,0)">);</span><span style=3D"color:rgb(0,0,0)"> </span><s=
pan style=3D"color:rgb(136,0,0)">//Implicit conversion from string.</span><=
/div></code></div><br>Or do you think that `basic_string` should have an im=
plicit conversion to &quot;array of bytes&quot;, which looses semantic info=
rmation?<br></div></div></blockquote><div></div></div><br></div><div>Jens h=
as a proposal for this, but it&#39;s based around ranges of characters:=C2=
=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0067=
r1.html" rel=3D"nofollow" target=3D"_blank" onmousedown=3D"this.href=3D&#39=
;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%=
2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0067r1.html\46sa\75D\46sntz\0751\46usg\75A=
FQjCNFN0t-UUEzs6iFgmKCDYMBnC2_zXA&#39;;return true;" onclick=3D"this.href=
=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%=
2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2016%2Fp0067r1.html\46sa\75D\46sntz\0751\46=
usg\75AFQjCNFN0t-UUEzs6iFgmKCDYMBnC2_zXA&#39;;return true;">http://www.open=
-<wbr>std.org/jtc1/sc22/wg21/docs/<wbr>papers/2016/p0067r1.html</a>. The co=
re problem with serializing to an unowned range is that you have to track h=
ow much space is available vs how much you&#39;ve used. At that point, you&=
#39;re not really representing a &quot;string&quot; anymore. You&#39;re rep=
resenting a byte array whose prefix is a string, and span&lt;char&gt; seems=
 better suited for that.</div></div></blockquote></span><div><br>Let&#39;s =
say that I accept the idea that the unowned range isn&#39;t technically a s=
tring yet (even though `basic_string` lets you make strings of value-initia=
lized CharT&#39;s of arbitrary length). Regardless of that, the return valu=
e would most assuredly be a real, honest-to-God string. It would be a `stri=
ng_span` of the appropriate range within the given range of characters pass=
ed in.<br></div></div><span>

<p></p>

</span></blockquote><div></div></div></div><div>Could you be more precise? =
I see an in/out parameter in your signature, not a return value. Clearly th=
e in/out parameter can&#39;t change types across the call. It&#39;d be tota=
lly fine to return a string_view the refers to a sub-range of the input spa=
n&lt;char&gt;, and that works with the current types.</div></div></blockquo=
te><div><br>It would not be &quot;totally fine&quot; because the return val=
ue is `const`. You&#39;re not merely referring to a subrange of another ran=
ge, but to a completely different type of range.<br><br>It&#39;d be like pa=
ssing a `vector&lt;T&gt;&amp;` to someone, and them returning a `span&lt;co=
nst T&gt;` into the vector. It makes no sense.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b5c72de8-d6d6-4be7-a352-3151dc42546e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b5c72de8-d6d6-4be7-a352-3151dc42546e=
%40isocpp.org</a>.<br />

------=_Part_16_710131461.1456453648424--
------=_Part_15_1485122172.1456453648419--

.

On quinta-feira, 25 de fevereiro de 2016 07:47:09 PST Nicol Bolas wrote:
> Now you're just digging yourself deeper. The reason being that `unsigned
> char` can also mean `UTF-8 code unit`. So is a `span<unsigned char>` an
> array of bytes or a UTF-8-encoded string?

I don't agree with your conclusion here.

You're reading from the part of the standard that requires unsigned char to be
able to contain a UTF-8 code unit. It doesn't mean UTF-8 code units are
unsigned char -- they aren't, as u8'a' is char, not unsigned char.

That passage of the standard is simply setting the lower limit for the size of
a byte: it needs to be large enough to contain a UTF-8 code unit (i.e.,
CHAR_BITS >= 8)

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6711611.2YkdcyW7T4%40tjmaciei-mobl4.

.

------=_Part_1664_1109599751.1456590705404
Content-Type: multipart/alternative;
 boundary="----=_Part_1665_1747140770.1456590705411"

------=_Part_1665_1747140770.1456590705411
Content-Type: text/plain; charset=UTF-8

On Saturday, February 27, 2016 at 2:51:52 AM UTC-5, Thiago Macieira wrote:
>
> On quinta-feira, 25 de fevereiro de 2016 07:47:09 PST Nicol Bolas wrote:
> > Now you're just digging yourself deeper. The reason being that `unsigned
> > char` can also mean `UTF-8 code unit`. So is a `span<unsigned char>` an
> > array of bytes or a UTF-8-encoded string?
>
> I don't agree with your conclusion here.
>
> You're reading from the part of the standard that requires unsigned char
> to be
> able to contain a UTF-8 code unit. It doesn't mean UTF-8 code units are
> unsigned char -- they aren't, as u8'a' is char, not unsigned char.
>

I am well aware of C++'s stupidities with regard to UTF-8. But what `u8`
returns is irrelevant. Why?

Because if you ever want to actually *do anything* with a sequence of UTF-8
code units, there is only one type that you can use that has well-defined
behavior: `unsigned char`. You can't perform UTF-8 decoding operations with
`char`, since `char` might be signed. That's why C++14 has that wording
that requires conversions between `char` and `unsigned char` to not disturb
UTF-8 code units' bit patterns.

I see no need to presume that `span<unsigned char>` means "array of bytes"
when it could mean "UTF-8 string". Unless of course you have a
`string_span` type; then you know exactly what it means.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b7a5c83e-f701-4bee-a6ed-705100e696c1%40isocpp.org.

------=_Part_1665_1747140770.1456590705411
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Saturday, February 27, 2016 at 2:51:52 AM UTC-5, Thiago=
 Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On quinta-feir=
a, 25 de fevereiro de 2016 07:47:09 PST Nicol Bolas wrote:
<br>&gt; Now you&#39;re just digging yourself deeper. The reason being that=
 `unsigned=20
<br>&gt; char` can also mean `UTF-8 code unit`. So is a `span&lt;unsigned c=
har&gt;` an=20
<br>&gt; array of bytes or a UTF-8-encoded string?
<br>
<br>I don&#39;t agree with your conclusion here.
<br>
<br>You&#39;re reading from the part of the standard that requires unsigned=
 char to be=20
<br>able to contain a UTF-8 code unit. It doesn&#39;t mean UTF-8 code units=
 are=20
<br>unsigned char -- they aren&#39;t, as u8&#39;a&#39; is char, not unsigne=
d char.
<br></blockquote><div><br>I am well aware of C++&#39;s stupidities with reg=
ard to UTF-8. But what `u8` returns is irrelevant. Why?<br><br>Because if y=
ou ever want to actually <i>do anything</i> with a sequence of UTF-8 code u=
nits, there is only one type that you can use that has well-defined behavio=
r: `unsigned char`. You can&#39;t perform UTF-8 decoding operations with `c=
har`, since `char` might be signed. That&#39;s why C++14 has that wording t=
hat requires conversions between `char` and `unsigned char` to not disturb =
UTF-8 code units&#39; bit patterns.<br><br>I see no need to presume that `s=
pan&lt;unsigned char&gt;` means &quot;array of bytes&quot; when it could me=
an &quot;UTF-8 string&quot;. Unless of course you have a `string_span` type=
; then you know exactly what it means.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b7a5c83e-f701-4bee-a6ed-705100e696c1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b7a5c83e-f701-4bee-a6ed-705100e696c1=
%40isocpp.org</a>.<br />

------=_Part_1665_1747140770.1456590705411--
------=_Part_1664_1109599751.1456590705404--

.

On s=C3=A1bado, 27 de fevereiro de 2016 08:31:45 PST Nicol Bolas wrote:
> I see no need to presume that `span<unsigned char>` means "array of bytes=
"=20
> when it could mean "UTF-8 string". Unless of course you have a=20
> `string_span` type; then you know exactly what it means.

It could also means "UTF-16 string" or"coordinates of a rectangle" for that=
=20
matter.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2089221.3mm7OVNJ1E%40tjmaciei-mobl4.

.