[string-ref] Name Suggestion

[Olaf van der Spek]

On Sat, Dec 29, 2012 at 2:42 PM, Beman Dawes <bda...@acm.org> wrote:
> On Fri, Dec 28, 2012 at 8:04 AM, Olaf van der Spek <olafv...@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

[Ville Voutilainen]

On 10 January 2013 16:06, Olaf van der Spek <olafv...@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.

[Klaim - Joël Lamotte]

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

[Vicente J. Botet Escriba]

Le 10/01/13 15:06, Olaf van der Spek a �crit :

> 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
to a C-string that behaves almost like a C++ std::string and defines a
substring of a not owned C-string. So string should be part of the name.
I don't like str.

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

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

Vicente

[Beman Dawes]

On Thu, Jan 10, 2013 at 9:06 AM, Olaf van der Spek <olafv...@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

[Mikael Kilpeläinen]

> 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

[Klaim - Joël Lamotte]

On Thu, Jan 10, 2013 at 5:31 PM, Beman Dawes <bda...@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

[Ville Voutilainen]

+1, string_view seems like a good name.

[Jeffrey Yasskin]

On Thu, Jan 10, 2013 at 8:31 AM, Beman Dawes <bda...@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?

[Vicente J. Botet Escriba]

Le 10/01/13 17:31, Beman Dawes a écrit :

On Thu, Jan 10, 2013 at 9:06 AM, Olaf van der Spek <olafv...@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.

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.

Vicente

[Zhihao Yuan]

On Thu, Jan 10, 2013 at 4:27 PM, Vicente J. Botet Escriba
<vicent...@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/

[Beman Dawes]

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

[Nicol Bolas]

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> wrote:
> On Thu, Jan 10, 2013 at 8:31 AM, Beman Dawes <bda...@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".

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.

[Daniel Krügler]

2013/1/11 Nicol Bolas <jmck...@gmail.com>:

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

- Daniel

[Olaf van der Spek]

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> 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.

[Zhihao Yuan]

On Fri, Jan 11, 2013 at 2:48 AM, Olaf van der Spek <olafv...@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'.

[Olaf van der Spek]

On Fri, Jan 11, 2013 at 10:17 AM, Zhihao Yuan <lic...@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 2:48 AM, Olaf van der Spek <olafv...@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

[Ville Voutilainen]

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

mutable_string_view is what I would call it.

[Olaf van der Spek]

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> 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.

[Tony V E]

On Fri, Jan 11, 2013 at 5:23 AM, Olaf van der Spek <olafv...@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

[Klaim - Joël Lamotte]

On Mon, Jan 14, 2013 at 3:41 AM, Tony V E <tvan...@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