On Sat, Dec 29, 2012 at 2:42 PM, Beman Dawes <bdawes@acm.org> wrote:
> On Fri, Dec 28, 2012 at 8:04 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> On Thursday, December 27, 2012 12:44:38 AM UTC+1, Jeffrey Yasskin wrote:
>>>
>>> I finally have an update for the string_ref proposal, converting it to
>>> a set of changes against the C++14 draft. The most recent version
>>> lives at
>>> https://github.com/google/cxx-std-draft/blob/string-ref-paper/string_ref.html,
>>> and I've attached a snapshot.
>
>> Is there still time for bike shedding? str_ref is ever so slightly shorter.
>
> Names are important, and I've planning to start such a discussion next
> week when more people will be reading this list. But if you want to
> start such a discussion now, feel free to do so. However, please start
> a separate message thread, with a subject line like "[string-ref] Name
> suggestion" so that (1) those that don't care can skip reading the
> thread and (2) other technical comments don't get lost in the noise.

Let's get the party started. What name do you suggest and why?

I think string_ref is a decent name, but I suggest str_ref myself.
string_ref is not a reference to std::string and str is a frequently
used term for strings in general.


--
Olaf

--




.

On 10 January 2013 16:06, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Let's get the party started. What name do you suggest and why?
> I think string_ref is a decent name, but I suggest str_ref myself.
> string_ref is not a reference to std::string and str is a frequently
> used term for strings in general.

I like string_ref better, it's a std::string-like object referring to
data. When I
see str*, I expect to get a low-level bag of bits (strcpy and its
ilk). Now, stringstream::str
doesn't really fit into this thinking, I admit, but I find string_ref
a perfectly good name
for the proposed facility.

--




.

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

I'm not exactly sure because
- if string_ref is directly related to std::string, then I prefer this name
because the relationship is obvious;
- if string_ref is not directly related to std::string then I prefer
an unambiguous name,
   but I don't know enough of the internal working of the current proposal
to propose an alternative;
- I don't like shortcuts that remove voyels because it makes verbal
communication ambiguous (I also tend to read then "S, T, R, ref").
  So I don't like str_ref personally. Also unique_ptr, shared_ptr, etc.
make it explicit that the important word in the name is complete,
  it would be good to keep this guideline of having the important words in
full letters.

As you say string_ref is not related to std::strings, I would prefer
another_ref.

my 2 cents.

Joel Lamotte

--




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

<div dir=3D"ltr">I&#39;m not exactly sure because=A0<div>- if string_ref is=
 directly related to std::string, then I prefer this name because the relat=
ionship is obvious;</div><div style>- if string_ref is not directly related=
 to std::string then I prefer an=A0unambiguous=A0name,=A0</div>
<div style>=A0 =A0but I don&#39;t know enough of the internal working of th=
e current proposal to propose an alternative;</div><div style>- I don&#39;t=
 like shortcuts that remove voyels because it makes verbal communication=A0=
ambiguous (I also tend to read then &quot;S, T, R, ref&quot;).</div>
<div style>=A0 So I don&#39;t like str_ref personally. Also unique_ptr, sha=
red_ptr, etc. make it explicit that the important word in the name is compl=
ete,=A0</div><div style>=A0 it would be good to keep this guideline of havi=
ng the important words in full letters.</div>
<div style><br></div><div style>As you say string_ref is not related to std=
::strings, I would prefer another_ref.</div><div style><br></div><div style=
>my 2 cents.<br><br>Joel Lamotte</div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--bcaec54d3edc85134c04d2f09654--

.

Le 10/01/13 15:06, Olaf van der Spek a =E9crit :
> Let's get the party started. What name do you suggest and why?
>
> I think string_ref is a decent name, but I suggest str_ref myself.
> string_ref is not a reference to std::string and str is a frequently
> used term for strings in general.
>
>
Even if the class is not forcedly related to a std::string it is related=20
to a C-string that behaves almost like a C++ std::string and defines a=20
substring of a not owned C-string. So string should be part of the name.=20
I don't like str.

string_view let think that the viewed string can not be modified by=20
view. I would expect from a string_range class with much less features=20
than the proposed class.

I don't like too much string_piece or string_chunk. I think substring or=20
sub_string defines quite well the intent of the proposed class.

Vicente


--=20




.

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

On Thu, Jan 10, 2013 at 9:06 AM, Olaf van der Spek <olafvdspek@gmail.com>wrote:

Let's get the party started. What name do you suggest and why?
>

My problem with "string_ref" is that "reference" has a very specific
meaning in the context of C++, and this proposal does not provide a C++
reference to a string. There have already been several examples on the
Boost list of people being badly misled by the "_ref" suffix, and much
effort wasted straightening them out.

The alternative that I prefer for the suffix is "_view", as in
"string_view" and "basic_string_view". It captures the functionality well
and signals a need to actually read the specs to figure out what it is.

My problem with the "basic_string_" prefix for the template version is that
the type provides a generic view (or reference, if you prefer) of a string,
not a view or reference of a basic_string. Thus I prefer
"generic_string_view" or "generic_string_ref".

--Beman

--




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

<div class=3D"gmail_quote">On Thu, Jan 10, 2013 at 9:06 AM, Olaf van der Sp=
ek <span dir=3D"ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"=
_blank">olafvdspek@gmail.com</a>&gt;</span> wrote:<br><br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
Let&#39;s get the party started. What name do you suggest and why?<br></blo=
ckquote><div><br>My problem with &quot;string_ref&quot; is that &quot;refer=
ence&quot; has a very specific meaning in the context of C++, and this prop=
osal does not provide a C++ reference to a string. There have already been =
several examples on the Boost list of people being badly misled by the &quo=
t;_ref&quot; suffix, and much effort wasted straightening them out.<br>
<br>The alternative that I prefer for the suffix is &quot;_view&quot;, as i=
n &quot;string_view&quot; and &quot;basic_string_view&quot;. It captures th=
e functionality well and signals a need to actually read the specs to figur=
e out what it is.<br>
<br>My problem with the &quot;basic_string_&quot; prefix for the template v=
ersion is that the type provides a generic view (or reference, if you prefe=
r) of a string, not a view or reference of a basic_string. Thus I prefer &q=
uot;generic_string_view&quot; or &quot;generic_string_ref&quot;.<br>
<br>--Beman<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--f46d04083e33c33d4004d2f1b56d--

.

> The alternative that I prefer for the suffix is "_view", as in
> "string_view" and "basic_string_view". It captures the functionality
> well and signals a need to actually read the specs to figure out what
> it is.
>
+1

Similar is _proxy


Mikael

--




.

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

On Thu, Jan 10, 2013 at 5:31 PM, Beman Dawes <bdawes@acm.org> wrote:

> The alternative that I prefer for the suffix is "_view", as in
> "string_view" and "basic_string_view". It captures the functionality well
> and signals a need to actually read the specs to figure out what it is.


+1 too, view seems to be the right name to me.

Joel Lamotte

--




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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Jan 10, 2013 at 5:31 PM, Beman Dawes <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bdawes@acm.org" target=3D"_blank">bdawes@acm.org</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,204,204);border-left-style:solid;p=
adding-left:1ex">The alternative that I prefer for the suffix is &quot;_vie=
w&quot;, as in &quot;string_view&quot; and &quot;basic_string_view&quot;. I=
t captures the functionality well and signals a need to actually read the s=
pecs to figure out what it is.</blockquote>
</div><br>+1 too, view seems to be the right name to me.</div><div class=3D=
"gmail_extra" style><br></div><div class=3D"gmail_extra" style>Joel Lamotte=
</div><div class=3D"gmail_extra" style><br></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--bcaec54c53d42a0f7a04d2f3bf7b--

.

On 10 January 2013 20:57, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:
> On Thu, Jan 10, 2013 at 5:31 PM, Beman Dawes <bdawes@acm.org> wrote:
>> The alternative that I prefer for the suffix is "_view", as in
>> "string_view" and "basic_string_view". It captures the functionality wel=
l
>> and signals a need to actually read the specs to figure out what it is.
> +1 too, view seems to be the right name to me.

+1, string_view seems like a good name.

--=20




.

On Thu, Jan 10, 2013 at 8:31 AM, Beman Dawes <bdawes@acm.org> wrote:
> My problem with the "basic_string_" prefix for the template version is that
> the type provides a generic view (or reference, if you prefer) of a string,
> not a view or reference of a basic_string. Thus I prefer
> "generic_string_view" or "generic_string_ref".

I somewhat agree that the standard was wrong to use "basic_*" as the
"templated version of" prefix, but that's what the standard picked. Is
there a strong enough reason that string_{ref,view} should be
inconsistent?

--




.

This is a multi-part message in MIME format.
--------------070208060703000904010806
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 10/01/13 17:31, Beman Dawes a =E9crit :
> On Thu, Jan 10, 2013 at 9:06 AM, Olaf van der Spek=20
> <olafvdspek@gmail.com <mailto:olafvdspek@gmail.com>> wrote:
>
>     Let's get the party started. What name do you suggest and why?
>
>
> My problem with "string_ref" is that "reference" has a very specific=20
> meaning in the context of C++, and this proposal does not provide a=20
> C++ reference to a string. There have already been several examples on=20
> the Boost list of people being badly misled by the "_ref" suffix, and=20
> much effort wasted straightening them out.
>
> The alternative that I prefer for the suffix is "_view", as in=20
> "string_view" and "basic_string_view". It captures the functionality=20
> well and signals a need to actually read the specs to figure out what=20
> it is.
>
After checking the proposal it seems that string_ref could not be used=20
to modify the reference string. If this is the case +1 for string_view.

Vicente

--=20




--------------070208060703000904010806
Content-Type: text/html; charset=ISO-8859-1

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Le 10/01/13 17:31, Beman Dawes a
      &eacute;crit&nbsp;:<br>
    </div>
    <blockquote
cite="mid:CAAygHNPDPQLng2-JnpT89QPXzmLegd9U5Pyp4xiUd1yh1gE5pQ@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Thu, Jan 10, 2013 at 9:06 AM, Olaf van
        der Spek <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:olafvdspek@gmail.com" target="_blank">olafvdspek@gmail.com</a>&gt;</span>
        wrote:<br>
        <br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          Let's get the party started. What name do you suggest and why?<br>
        </blockquote>
        <div><br>
          My problem with "string_ref" is that "reference" has a very
          specific meaning in the context of C++, and this proposal does
          not provide a C++ reference to a string. There have already
          been several examples on the Boost list of people being badly
          misled by the "_ref" suffix, and much effort wasted
          straightening them out.<br>
          <br>
          The alternative that I prefer for the suffix is "_view", as in
          "string_view" and "basic_string_view". It captures the
          functionality well and signals a need to actually read the
          specs to figure out what it is.<br>
          <br>
        </div>
      </div>
    </blockquote>
    After checking the proposal it seems that string_ref could not be
    used to modify the reference string. If this is the case +1 for
    string_view.<br>
    <br>
    Vicente<br>
  </body>
</html>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--------------070208060703000904010806--

.

On Thu, Jan 10, 2013 at 4:27 PM, Vicente J. Botet Escriba
<vicente.botet@wanadoo.fr> wrote:
> After checking the proposal it seems that string_ref could not be used to
> modify the reference string. If this is the case +1 for string_view.

Me too.  The first time I saw the name, I guess it can potentially
modified the referred string, but it can not, by design.  *_view may
not be the best choice, but, at least, it's clearer than *_ref.

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

--




.

On Thu, Jan 10, 2013 at 2:37 PM, Jeffrey Yasskin <jyasskin@googlers.com> wrote:
> On Thu, Jan 10, 2013 at 8:31 AM, Beman Dawes <bdawes@acm.org> wrote:
>> My problem with the "basic_string_" prefix for the template version is that
>> the type provides a generic view (or reference, if you prefer) of a string,
>> not a view or reference of a basic_string. Thus I prefer
>> "generic_string_view" or "generic_string_ref".
>
> I somewhat agree that the standard was wrong to use "basic_*" as the
> "templated version of" prefix, but that's what the standard picked. Is
> there a strong enough reason that string_{ref,view} should be
> inconsistent?

The point is that since the standard library uses "basic_" as the
prefix for its templated string class, string_{ref,view} has to use a
different prefix since it doesn't provide a {ref,view} of a
basic_string. Instead it provides a {ref,view} of any string that
consists of contiguous characters, and happens to provide an interface
that overlaps the basic_string interface.

So we could call it {generic,contiguous, whatever}_string_{ref,view}
as long as "whatever" isn't "basic".

Please note that I don't feel anywhere near as strongly about a better
name for basic_ as I do about a better name for _ref.

--Beman

--




.

------=_Part_310_29661894.1357869387105
Content-Type: text/plain; charset=ISO-8859-1



On Thursday, January 10, 2013 5:43:12 PM UTC-8, Beman Dawes wrote:
>
> On Thu, Jan 10, 2013 at 2:37 PM, Jeffrey Yasskin <jyas...@googlers.com<javascript:>>
> wrote:
> > On Thu, Jan 10, 2013 at 8:31 AM, Beman Dawes <bda...@acm.org<javascript:>>
> wrote:
> >> My problem with the "basic_string_" prefix for the template version is
> that
> >> the type provides a generic view (or reference, if you prefer) of a
> string,
> >> not a view or reference of a basic_string. Thus I prefer
> >> "generic_string_view" or "generic_string_ref".
> >
> > I somewhat agree that the standard was wrong to use "basic_*" as the
> > "templated version of" prefix, but that's what the standard picked. Is
> > there a strong enough reason that string_{ref,view} should be
> > inconsistent?
>
> The point is that since the standard library uses "basic_" as the
> prefix for its templated string class, string_{ref,view} has to use a
> different prefix since it doesn't provide a {ref,view} of a
> basic_string. Instead it provides a {ref,view} of any string that
> consists of contiguous characters, and happens to provide an interface
> that overlaps the basic_string interface.
>
> So we could call it {generic,contiguous, whatever}_string_{ref,view}
> as long as "whatever" isn't "basic".
>

So how do you explain "basic_istream" and so forth?

The C++ standard library consistenly uses "basic_" for "template types that
deal with `char`-like objects". basic_string_ref/view/etc is very clearly
one of them, like basic_string, basic_ostringstream, and so forth. So we
should be consistent with that.

--




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

<br><br>On Thursday, January 10, 2013 5:43:12 PM UTC-8, Beman Dawes wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 10, 2013 at 2:37 PM=
, Jeffrey Yasskin &lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfusca=
ted-mailto=3D"1lHyKbSaMykJ">jyas...@googlers.com</a>&gt; wrote:
<br>&gt; On Thu, Jan 10, 2013 at 8:31 AM, Beman Dawes &lt;<a href=3D"javasc=
ript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1lHyKbSaMykJ">bda...@acm.=
org</a>&gt; wrote:
<br>&gt;&gt; My problem with the "basic_string_" prefix for the template ve=
rsion is that
<br>&gt;&gt; the type provides a generic view (or reference, if you prefer)=
 of a string,
<br>&gt;&gt; not a view or reference of a basic_string. Thus I prefer
<br>&gt;&gt; "generic_string_view" or "generic_string_ref".
<br>&gt;
<br>&gt; I somewhat agree that the standard was wrong to use "basic_*" as t=
he
<br>&gt; "templated version of" prefix, but that's what the standard picked=
.. Is
<br>&gt; there a strong enough reason that string_{ref,view} should be
<br>&gt; inconsistent?
<br>
<br>The point is that since the standard library uses "basic_" as the
<br>prefix for its templated string class, string_{ref,view} has to use a
<br>different prefix since it doesn't provide a {ref,view} of a
<br>basic_string. Instead it provides a {ref,view} of any string that
<br>consists of contiguous characters, and happens to provide an interface
<br>that overlaps the basic_string interface.
<br>
<br>So we could call it {generic,contiguous, whatever}_string_{ref,view}
<br>as long as "whatever" isn't "basic".<br></blockquote><div><br>So how do=
 you explain "basic_istream" and so forth?<br><br>The C++ standard library =
consistenly uses "basic_" for "template types that deal with `char`-like ob=
jects". basic_string_ref/view/etc is very clearly one of them, like basic_s=
tring, basic_ostringstream, and so forth. So we should be consistent with t=
hat.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_310_29661894.1357869387105--

.

2013/1/11 Nicol Bolas <jmckesson@gmail.com>:
>
> On Thursday, January 10, 2013 5:43:12 PM UTC-8, Beman Dawes wrote:
>>
>> The point is that since the standard library uses "basic_" as the
>> prefix for its templated string class, string_{ref,view} has to use a
>> different prefix since it doesn't provide a {ref,view} of a
>> basic_string. Instead it provides a {ref,view} of any string that
>> consists of contiguous characters, and happens to provide an interface
>> that overlaps the basic_string interface.
>>
>> So we could call it {generic,contiguous, whatever}_string_{ref,view}
>> as long as "whatever" isn't "basic".
>
> So how do you explain "basic_istream" and so forth?
>
> The C++ standard library consistenly uses "basic_" for "template types that
> deal with `char`-like objects". basic_string_ref/view/etc is very clearly
> one of them, like basic_string, basic_ostringstream, and so forth. So we
> should be consistent with that.

I agree with Nicol: I'm very much in favor for using 'basic' as prefix here.

- Daniel

--




.

------=_Part_391_21953943.1357894088274
Content-Type: text/plain; charset=ISO-8859-1

On Friday, January 11, 2013 2:19:42 AM UTC+1, Zhihao Yuan wrote:

> On Thu, Jan 10, 2013 at 4:27 PM, Vicente J. Botet Escriba
> <vicent...@wanadoo.fr <javascript:>> wrote:
> > After checking the proposal it seems that string_ref could not be used
> to
> > modify the reference string. If this is the case +1 for string_view.
>
> Me too.  The first time I saw the name, I guess it can potentially
> modified the referred string, but it can not, by design.  *_view may
> not be the best choice, but, at least, it's clearer than *_ref.
>
>
Potential for a mutable_string_ref/view still exists. I use such a class,
but not as often as the const version.
Are you favoring view for the const aspect? That doesn't seem right.

--




------=_Part_391_21953943.1357894088274
Content-Type: text/html; charset=ISO-8859-1

On Friday, January 11, 2013 2:19:42 AM UTC+1, Zhihao Yuan wrote:<br><blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Thu, Jan 10, 2013 at 4:27 PM, Vicente J. Botet Escriba
<br>&lt;<a href="javascript:" target="_blank" gdf-obfuscated-mailto="M4s04G8uhkAJ">vicent...@wanadoo.fr</a>&gt; wrote:
<br>&gt; After checking the proposal it seems that string_ref could not be used to
<br>&gt; modify the reference string. If this is the case +1 for string_view.
<br>
<br>Me too. &nbsp;The first time I saw the name, I guess it can potentially
<br>modified the referred string, but it can not, by design. &nbsp;*_view may
<br>not be the best choice, but, at least, it's clearer than *_ref.
<br><br></blockquote><div><br></div><div>Potential for a mutable_string_ref/view still exists. I use such a class, but not as often as the const version.</div><div>Are you favoring view for the const aspect? That doesn't seem right.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_391_21953943.1357894088274--

.

On Fri, Jan 11, 2013 at 2:48 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> Are you favoring view for the const aspect? That doesn't seem right.

True, but from my point of view, the meaning of 'view' is closer to
'const' (which means 'read-only' in C++) than that of 'ref'.

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

--




.

On Fri, Jan 11, 2013 at 10:17 AM, Zhihao Yuan <lichray@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 2:48 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Are you favoring view for the const aspect? That doesn't seem right.
>
> True, but from my point of view, the meaning of 'view' is closer to
> 'const' (which means 'read-only' in C++) than that of 'ref'.

What would you call the non-const version of string-ref?
--
Olaf

--




.

On 11 January 2013 11:19, Olaf van der Spek <olafvdspek@gmail.com> wrote:
> What would you call the non-const version of string-ref?

mutable_string_view is what I would call it.

--




.

------=_Part_392_2746351.1357899796908
Content-Type: text/plain; charset=ISO-8859-1

Op donderdag 10 januari 2013 17:31:25 UTC+1 schreef Beman Dawes het
volgende:

> On Thu, Jan 10, 2013 at 9:06 AM, Olaf van der Spek <olafv...@gmail.com<javascript:>
> > wrote:
>
> Let's get the party started. What name do you suggest and why?
>>
>
> My problem with "string_ref" is that "reference" has a very specific
> meaning in the context of C++, and this proposal does not provide a C++
> reference to a string. There have already been several examples on the
> Boost list of people being badly misled by the "_ref" suffix, and much
> effort wasted straightening them out.
>

W.r.t. boost::string_ref? Was this on the users list? I must've missed it.


> The alternative that I prefer for the suffix is "_view", as in
> "string_view" and "basic_string_view". It captures the functionality well
> and signals a need to actually read the specs to figure out what it is.
>

We've got multiple kinds of pointers (raw, intrusive, shared, unique), why
can't we have multiple kinds of references? It basically is a kind of
reference.
I expect const string& to be replaced by string_ref as function parameter
type in a lot of cases.

--




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

Op donderdag 10 januari 2013 17:31:25 UTC+1 schreef Beman Dawes het volgend=
e:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div class=3D"gmail_quot=
e">On Thu, Jan 10, 2013 at 9:06 AM, Olaf van der Spek <span dir=3D"ltr">&lt=
;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Xk3a80j=
Wir4J">olafv...@gmail.com</a>&gt;</span> wrote:<br><br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
Let's get the party started. What name do you suggest and why?<br></blockqu=
ote><div><br>My problem with "string_ref" is that "reference" has a very sp=
ecific meaning in the context of C++, and this proposal does not provide a =
C++ reference to a string. There have already been several examples on the =
Boost list of people being badly misled by the "_ref" suffix, and much effo=
rt wasted straightening them out.<br></div></div></blockquote><div><br></di=
v><div>W.r.t. boost::string_ref? Was this on the users list? I must've miss=
ed it.</div><div>&nbsp;<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div class=3D"gmail_quote"><div>The alternative that I prefer for the su=
ffix is "_view", as in "string_view" and "basic_string_view". It captures t=
he functionality well and signals a need to actually read the specs to figu=
re out what it is.</div></div></blockquote><div><br></div><div>We've got mu=
ltiple kinds of pointers (raw, intrusive, shared, unique), why can't we hav=
e multiple kinds of references? It basically is a kind of reference.</div><=
div>I expect const string&amp; to be replaced by string_ref as function par=
ameter type in a lot of cases.</div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

------=_Part_392_2746351.1357899796908--

.

On Fri, Jan 11, 2013 at 5:23 AM, Olaf van der Spek <olafvdspek@gmail.com> wrote:

>>
>> The alternative that I prefer for the suffix is "_view", as in
>> "string_view" and "basic_string_view". It captures the functionality well
>> and signals a need to actually read the specs to figure out what it is.
>
>
> We've got multiple kinds of pointers (raw, intrusive, shared, unique), why
> can't we have multiple kinds of references? It basically is a kind of
> reference.
> I expect const string& to be replaced by string_ref as function parameter
> type in a lot of cases.
>

(raw, intrusive, shared, unique) describe the type of pointer, not
what it points to.  Does string_ref describe the ref, or the values?
If it is the ref, maybe contiguous_ref would be better.  Still not
quite describing the ref the way the *_ptrs are named, more like
describing a property of what it is referring to.


Another suggestion (which maybe was briefly mentioned before?), why
not just std::substring?  The "sub" gives quite a clue that it is just
referencing a part of something else, not the owner of the string.
And I think everyone would be comfortable with the concept that a
std::string could convert to a substring that spans the entire string.

Tony

--




.

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

On Mon, Jan 14, 2013 at 3:41 AM, Tony V E <tvaneerd@gmail.com> wrote:

> Another suggestion (which maybe was briefly mentioned before?), why
> not just std::substring?  The "sub" gives quite a clue that it is just
> referencing a part of something else, not the owner of the string.
> And I think everyone would be comfortable with the concept that a
> std::string could convert to a substring that spans the entire string.
>

AFAIK it's not always associated to std::string and it's not a part of
another string, it
could be a full string or not.
Also it would make things ambiguous with std::substr()

Joel Lamotte

--




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

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, Jan 14, 2013 at 3:41 AM, Tony V E <span dir=3D"ltr">&lt;<a href=3D"=
mailto:tvaneerd@gmail.com" target=3D"_blank">tvaneerd@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div id=3D":1jr">Another suggestion (which m=
aybe was briefly mentioned before?), why<br>
not just std::substring? =A0The &quot;sub&quot; gives quite a clue that it =
is just<br>
referencing a part of something else, not the owner of the string.<br>
And I think everyone would be comfortable with the concept that a<br>
std::string could convert to a substring that spans the entire string.</div=
></blockquote></div><br>AFAIK it&#39;s not always associated to std::string=
 and it&#39;s not a part of another string, it</div><div class=3D"gmail_ext=
ra">
could be a full string or not.</div><div class=3D"gmail_extra" style>Also i=
t would make things ambiguous with std::substr()</div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra" style>Joel Lamotte</div><div cla=
ss=3D"gmail_extra" style>
<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
&nbsp;<br />
&nbsp;<br />

--e89a8fb20446d2c8b304d33b3666--

.