220 8656 article Path: news.gmane.org!not-for-mail From: Peter Bigot Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Fri, 17 Jan 2014 15:25:00 -0600 Lines: 146 Approved: news@gmane.org Message-ID: References: <8045a4d2-721d-4725-8bb7-7a91b6f53ec8@isocpp.org> <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> <7aad44d8-6b4e-438a-b309-bd898b994b34@isocpp.org> <9C2C439F-7983-4224-B272-53CAD0E2E456@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33c914b321fa04f0312c58 X-Trace: ger.gmane.org 1389993895 22981 80.91.229.3 (17 Jan 2014 21:24:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 17 Jan 2014 21:24:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA3LUEAQACBBLN742LAKGQE4UR7AMA@isocpp.org Fri Jan 17 22:25:03 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4GuU-0004CN-Ph for gclcip-std-proposals@m.gmane.org; Fri, 17 Jan 2014 22:25:03 +0100 Original-Received: by mail-ie0-f198.google.com with SMTP id ar20sf4257842iec.1 for ; Fri, 17 Jan 2014 13:25:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=ncK3QVcHnPv4LgyszyAOXn3jC1K4G11cnqyEBg2RKUc=; b=NBjTmgm4Ob00JRManBqVzsOjpowsyxKRrJaM7tC8112izVfh2RlsT0X3OuSnrjkVSD 3hBSIqv+yMSFkZ2Q5y3hCP0yrb+UhpmKjOvPe//pwB9hkRc/7GyDD5uJOZFKoqsgK+7A dxA4ocPXawLH/OyCfKum9ZBD6pE5UXV8kCMZOME0UmUxZPvWy2n/iZuchTdpRxOIwued zSgdQqmrLNj7dXtedRVQq48ZnzizYMCatzCzxhLToAXww2LL/Fr4NetjlLHNLSquQiji kecm0YjiDNNf3f6iNrNoQcNwEde1di16UgSpIhdQMtR2CJl4lYlwBVSLHs6Sd8zd1Fjq 6l2w== X-Gm-Message-State: ALoCoQnSnMrOJ9avnxGVvzvXJpvpM3Jl2ItfGlRc/ZWgsWwSPAJpI8Cl+sOb+9wEEjFCAGAbUtNz X-Received: by 10.182.104.70 with SMTP id gc6mr1558930obb.35.1389993901871; Fri, 17 Jan 2014 13:25:01 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.30.70 with SMTP id c64ls594973qgc.26.gmail; Fri, 17 Jan 2014 13:25:01 -0800 (PST) X-Received: by 10.236.26.17 with SMTP id b17mr3872963yha.77.1389993901278; Fri, 17 Jan 2014 13:25:01 -0800 (PST) Original-Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [2607:f8b0:4003:c01::22b]) by mx.google.com with ESMTPS id q48si11273546yhb.2.2014.01.17.13.25.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 13:25:01 -0800 (PST) Received-SPF: pass (google.com: domain of pabigot@gmail.com designates 2607:f8b0:4003:c01::22b as permitted sender) client-ip=2607:f8b0:4003:c01::22b; Original-Received: by mail-ob0-f171.google.com with SMTP id wm4so4926813obc.2 for ; Fri, 17 Jan 2014 13:25:00 -0800 (PST) X-Received: by 10.60.119.70 with SMTP id ks6mr3488738oeb.45.1389993900840; Fri, 17 Jan 2014 13:25:00 -0800 (PST) Original-Sender: pabigot@gmail.com Original-Received: by 10.76.168.228 with HTTP; Fri, 17 Jan 2014 13:25:00 -0800 (PST) In-Reply-To: X-Original-Sender: bigotp@acm.org X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of pabigot@gmail.com designates 2607:f8b0:4003:c01::22b as permitted sender) smtp.mail=pabigot@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:8656 Archived-At: --047d7b33c914b321fa04f0312c58 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Jan 17, 2014 at 2:22 PM, Jeffrey Yasskin wrote: > On Fri, Jan 17, 2014 at 12:18 PM, Nevin Liber > wrote: > > On 17 January 2014 14:11, Jeffrey Yasskin wrote: > >> > >> If it is, I intend to also > >> remove the precondition on the string_view(data, size) to let people > >> explicitly put nullptr in. > > > > > > I'd like to, mainly because it makes it easy to create a string_view > from a > > vector by using v.data() and v.size(). Having to special case a > check > > for nullptr (such as in string::string(const char*, size_t)) for what is > > otherwise a perfectly valid 0-sized range is just annoying. > > Ah, vector.data() doesn't guarantee non-null results. :( That's a good > argument. > First, is that true? [data(), data()+size()) must be a valid range, but I've been unable to find a definition of "valid range" in the standard so I could understand whether an empty valid range permits its base to be a null pointer. Second, even if so std::string.data() does guarantee a non-null result, doesn't it? In that case it's also required that data()+i == &operator[](i) for i in [0, size()] which led me to believe data() could not be null, since the equality must hold for i==0 and operator[] must return a reference to an object (hence the underlying pointer cannot be null). I've been swayed by the argument that there's no such thing as a null std::string, so there should be no such thing as a null std::string_view. This is easily assured by disallowing std::string_view(s, n) for a null s just as std::string(s, n) is disallowed for null s. I don't see it as unreasonable to require a check for that situation before creating a std::string_view in situations where a char* pointer comes from a source that might produce a null pointer. As Nevin points out, you have to do it for std::string too. Personally, I'd find it more annoying to have to constantly check in every utility function that operates on string_view instances whether an input sv.data() is null in addition to whether sv.size() is zero. I understood std::string_view to serve the role of a reference type compatible with both character arrays and std::strings, so just as with other reference types it shouldn't be possible for the underlying pointer to be null. My opinion, at any rate. Peter -- --- 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/. --047d7b33c914b321fa04f0312c58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On F= ri, Jan 17, 2014 at 2:22 PM, Jeffrey Yasskin <jyasskin@google.com&g= t; wrote:
On Fri, Jan 17, 2014 at 12= :18 PM, Nevin Liber <nevin@evi= loverlord.com> wrote:
> On 17 January 2014 14:11, Jeffrey Yasskin <jyasskin@google.com> wrote:
>>
>> If it is, I intend to also
>> remove the precondition on the string_view(data, size) to let peop= le
>> explicitly put nullptr in.
>
>
> I'd like to, mainly because it makes it easy to create a string_vi= ew from a
> vector<char> by using v.data() and v.size(). =A0Having to specia= l case a check
> for nullptr (such as in string::string(const char*, size_t)) for what = is
> otherwise a perfectly valid 0-sized range is just annoying.
<= /blockquote>

Ah, vector.data() doesn't guarantee non-null results. :( That'= ;s a good argument.

First, is that true= ?=A0 [data(), data()+size()) must be a valid range, but I've been unabl= e to find a definition of "valid range" in the standard so I coul= d understand whether an empty valid range permits its base to be a null poi= nter.

Second, even if so std::st= ring.data() does guarantee a non-null result, doesn't it?=A0 In that ca= se it's also required that data()+i =3D=3D &operator[](i) for i in = [0, size()] which led me to believe data() could not be null, since the equ= ality must hold for i=3D=3D0 and operator[] must return a reference to an o= bject (hence the underlying pointer cannot be null).

I've been swayed by the argument that there's no such thing as = a null std::string, so there should be no such thing as a null std::string_= view.=A0 This is easily assured by disallowing std::string_view(s, n) for a= null s just as std::string(s, n) is disallowed for null s.

I don't see it as unreasonable to require a check for that situatio= n before creating a std::string_view in situations where a char* pointer co= mes from a source that might produce a null pointer.=A0 As Nevin points out= , you have to do it for std::string too.

Personally, I'd find it more annoying to have to constantly check i= n every utility function that operates on string_view instances whether an = input sv.data() is null in addition to whether sv.size() is zero.=A0 I unde= rstood std::string_view to serve the role of a reference type compatible wi= th both character arrays and std::strings, so just as with other reference = types it shouldn't be possible for the underlying pointer to be null.
My opinion, at any rate.

Peter
=

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7b33c914b321fa04f0312c58-- .