220 8278 article Path: news.gmane.org!not-for-mail From: Jeffrey Yasskin Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Sat, 28 Dec 2013 09:59:37 -0800 Lines: 150 Approved: news@gmane.org Message-ID: References: <8045a4d2-721d-4725-8bb7-7a91b6f53ec8@isocpp.org> <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bdc90bc8f2fac04ee9bfa65 X-Trace: ger.gmane.org 1388253593 16195 80.91.229.3 (28 Dec 2013 17:59:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Dec 2013 17:59:53 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDM34EO6QDRBHVD7SKQKGQEOHOKUBQ@isocpp.org Sat Dec 28 18:59:59 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gg0-f200.google.com ([209.85.161.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VwyB5-0007AJ-Dm for gclcip-std-proposals@m.gmane.org; Sat, 28 Dec 2013 18:59:59 +0100 Original-Received: by mail-gg0-f200.google.com with SMTP id p1sf11372332ggn.11 for ; Sat, 28 Dec 2013 09:59:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject: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=NCR10AP8DluB2uIut1dlYJ2ER19u3fnCO8lSB0eKR9g=; b=BpAVgKFssgPR8Rwshc8Gpk1EU7jWo7TgORdOSVeg3CEcocY1V+0kzgmlKwpnIqDZrM iHJPzwg40gQWzQHFtTZWe/dZCBHLbinXfLIPw1fUymolMtvJqHNx9bhJUWAw+Z3RPf2K A0hSzGfK7LsPfDTDc4W7zBkgst4VzwKYciWMl9FiibThw098yZY6hKBSSioOETBoZMXY nhrr8VCosRRfb+nWMGky8L84JdgPuBl/pELBhUoueaeRxrLNAMLTlXMgkP6cSb38LDRH TsDa2D7OsrdYn67AKMH1TQe5sAdFfL1fnJk3JjKMMKppg5581CqZ4zeOkmnnHv00LdbU o/Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=NCR10AP8DluB2uIut1dlYJ2ER19u3fnCO8lSB0eKR9g=; b=FkswqYEYEpU1sCRzh0i+eG5hNQQo1IAJ8tA9b8soPoEdPOvNoJsV03reuN9/2AwI9/ /rfVRPQ9ur5JlCGZAf8h0wtwzdOPwtjXL8v4Uic7Zq9tc3wPvm3Cmwq5MmOR8iozplX5 p43HNO3QP20ARK9ctfnosyM2kHuN5RmaXyGIshkEAmEzBtYIye/rC8+K9ETx9o1Q9VpK BapEz4s63j/BSxViHPZbWHkAR9kRjLFduB7b9OKZ2jdwjyFq6TxBpaQ+mqFxJqY+6nKK VvyKVCLxLIx/5Si8QnVgWaJrwqfFOUZZ7xvML2pBWprafnHKEFbKlRSlZXkzY1LoKefW iEZw== X-Gm-Message-State: ALoCoQl6EHReZCsmJNsahJJlY+7JnWPweUSPa7SDsXw22K6KoT4Y+YXCv30JwtEzlII4McQj1p3N X-Received: by 10.58.145.233 with SMTP id sx9mr16665317veb.0.1388253598577; Sat, 28 Dec 2013 09:59:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.130.195 with SMTP id og3ls3210937qeb.62.gmail; Sat, 28 Dec 2013 09:59:58 -0800 (PST) X-Received: by 10.229.24.4 with SMTP id t4mr90379253qcb.13.1388253598017; Sat, 28 Dec 2013 09:59:58 -0800 (PST) Original-Received: from mail-qe0-x236.google.com (mail-qe0-x236.google.com [2607:f8b0:400d:c02::236]) by mx.google.com with ESMTPS id q18si34040858qeu.44.2013.12.28.09.59.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Dec 2013 09:59:58 -0800 (PST) Received-SPF: pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400d:c02::236 as permitted sender) client-ip=2607:f8b0:400d:c02::236; Original-Received: by mail-qe0-f54.google.com with SMTP id cy11so10244978qeb.27 for ; Sat, 28 Dec 2013 09:59:57 -0800 (PST) X-Received: by 10.224.16.80 with SMTP id n16mr91914992qaa.42.1388253597865; Sat, 28 Dec 2013 09:59:57 -0800 (PST) Original-Received: by 10.229.208.138 with HTTP; Sat, 28 Dec 2013 09:59:37 -0800 (PST) In-Reply-To: <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> X-Original-Sender: jyasskin@google.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of jyasskin@google.com designates 2607:f8b0:400d:c02::236 as permitted sender) smtp.mail=jyasskin@google.com; dkim=pass header.i=@google.com; dmarc=pass (p=REJECT dis=NONE) header.from=google.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:8278 Archived-At: --047d7bdc90bc8f2fac04ee9bfa65 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Dec 27, 2013 at 9:01 PM, Marshall Clow wrote= : > On Dec 27, 2013, at 4:52 AM, abolz.lists@gmail.com wrote: > > Is there a reason why string_view is not nullable? > Nullable here means default constructed or constructed from a nullptr > (and a zero length). Then adding a is_null() (or null()) member > function which can then be used to distinguish the string_view from an > empty string. > > > i think that attempting to distinguish between an empty string_view that > =93used to point at something=94 > and an empty string view =93that never pointed at anything=94 is a use ca= se to > be discouraged, rather than > something that should be enshrined in the standard. > > This should not affect data() which returns a non-null pointer. > > I disagree here with the proposal as currently written. > I believe that the requirement that data() always return a non-null > pointer is misguided. > > if sv.size () =3D=3D 0 or sv.empty () [same thing], there is nothing that= you > can do with sv.data() > (except compare it to null, and that doesn=92t tell you anything useful). > The thing is, if nullptr is a possible return value for data(), people do start using it to convey information. If they get a null out exactly when they put a null in, it is telling them something useful. The only way to "discourage" it is to make it never happen. If we let string_view::data() pass through null, we're enshrining the use you don't like in the standard. > > An empty string view need not point *anywhere*, or have any data behind i= t. > > =97 Marshall > > P.S. In my implementation, I=92m tempted to have a default-constructed > string_view return a value of 1 from data(). > That's totally fine on all the platforms I've ever used. There are a few I've heard of where it could be a problem, but no need to worry about those until your implementation gets ported to them. --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --047d7bdc90bc8f2fac04ee9bfa65 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 27, 2013 at 9:01 PM, Marshall Clow <mclow.lis= ts@gmail.com> wrote:
On Dec 27, 2013, at 4:52 AM, abolz.lists@gmail.com wrote:

Is there a reason why string_view is not nullable?

Nullable her= e=A0means default constructed or constructed from a nullptr
(and = a zero length). Then adding a is_null() (or null()) member
function which can then be used to distinguish the string_view from an=
empty string.

i thi= nk that attempting to distinguish between an empty string_view that =93used= to point at something=94
and an empty string view =93that never pointed at anything=94 is a use= case to be discouraged, rather than
something that should be ens= hrined in the standard.

This should not affect data() which returns a non-null = pointer.

I disagree here with the pr= oposal as currently written.
I believe that the requirement = that data() always return a non-null pointer is misguided.=A0

if sv.size () =3D=3D 0 or s= v.empty () [same thing], there is nothing that you can do with sv.data()
(except compare it to null, and that doesn=92t tell you anything usefu= l).

The thing is, if nullptr is= a possible return value for data(), people do start using it to convey inf= ormation. If they get a null out exactly when they put a null in, it is tel= ling them something useful. The only way to "discourage" it is to= make it never happen. If we let string_view::data() pass through null, we&= #39;re enshrining the use you don't like in the standard.
=A0

An empty string view need not point *anywhere*, o= r have any data behind it.

=97 Mars= hall

P.S. In my implementation,=A0I=92m tempted to have a default-c= onstructed string_view return a value of 1 from data().

That's totally fine on all the p= latforms I've ever used. There are a few I've heard of where it cou= ld be a problem, but no need to worry about those until your implementation= gets ported to them.

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