Re: [boost] Heads up - string_ref landing

Subject: Re: [boost] Heads up - string_ref landing
From: Jeff Flinn (Jeffrey.Flinn_at_[hidden])
Date: 2012-12-12 11:46:51

On 12/12/2012 10:54 AM, Rob Stewart wrote:
> On Dec 12, 2012, at 8:26 AM, Jeff Flinn <Jeffrey.Flinn_at_[hidden]> wrote:
>
>> On 12/12/2012 2:50 AM, Yakov Galka wrote:
>>> On Sun, Dec 9, 2012 at 3:13 PM, Rob Stewart <robertstewart_at_[hidden]>wrote:
>>>
>>>>
>>>>>> - char const * data()
>>>>>> - size_t length()
>>>>> I propose the alias size().
>>>>
>>>> string_ref isn't a container like string, so I prefer just length().
>>>
>>>
>>> I propose adding size() and throwing length() away.
>>> Really.
>>>
>>> 1. According to the standard, string is not a container either.
>
> Ok, but string contains both.
>
>>> 2. initializer_list, which is semantically very similar to string_ref, does use .size().
>
> OK
>
>>> 3. Leaving the scope of the standard, Boost.Range uses boost::size(x) for ranges. I.e. size is a property of a range, not a container.
>
> OK
>
>>> 4. I always found string::length() to be an inconsistency in the standard
>>> library. I guess the reason for its existence is purely historical.
>
> I don't consider it a defect. It is the common vernacular to speak of a string's length.
>
>> +1
>>
>> I've got template code that currently takes, string's and vector<char>'s and uses size. With string_ref being a natural candidate, I'd hope it would work out of the box.
>
> That's a reasonable argument.
>
> Perhaps both size() and length() are appropriate.

Seems reasonable.

Jeff