220 8279 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: Sat, 28 Dec 2013 11:21:12 -0800 (PST) Lines: 152 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="----=_Part_1548_9020491.1388258472691" X-Trace: ger.gmane.org 1388258469 31247 80.91.229.3 (28 Dec 2013 19:21:09 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 Dec 2013 19:21:09 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDA3LUEAQACBBKOJ7SKQKGQESYVBOYI@isocpp.org Sat Dec 28 20:21:16 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f197.google.com ([209.85.192.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VwzRj-0006v3-An for gclcip-std-proposals@m.gmane.org; Sat, 28 Dec 2013 20:21:15 +0100 Original-Received: by mail-pd0-f197.google.com with SMTP id v10sf29517725pde.0 for ; Sat, 28 Dec 2013 11:21:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=hz8cdtd6X2CYRtvTfcHqmzru8j4FukYSqQ9aUCOwUO4=; b=JShNJvTCj4IKJQvL29dzkELGgDlCVqNyraBWGmxXUOkSOzqn+OzCTGCu7TqL1N568d u8mwQtVRK3djMoWm4lKtDSeghWG4kLSXXkD/pd0HSYQ44cKtlNRum5kmkMs+0wO8uFLt tHM4Qy7RkJcjKVvQZLRa2jvoDMLhmCqCB9tuUc/vu2lyUUmWkOx3dipkcFfBG73eiphY 1J7nXzDyU0czvxqdlV1rA/HF9o27vo/1Fcuv1lqJbtomD5KFb9Rq6qIEAmKfTVnZiN/r 6JZURbVXH9qqWqr4BTQX92jGt4XWEY6rGXY1Yyak1/r0ZQzidzPI/Suc5rSxpPER/uLS hjHw== X-Gm-Message-State: ALoCoQkhkGUJXdCcs3QVFEY50HqpGaC+e5ljNqFopONq0OOG68rWFkn1SI2jRc2CKIb+7dlwre0c X-Received: by 10.66.138.79 with SMTP id qo15mr21773761pab.34.1388258474032; Sat, 28 Dec 2013 11:21:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.22.77 with SMTP id b13ls1285698obf.36.gmail; Sat, 28 Dec 2013 11:21:13 -0800 (PST) X-Received: by 10.182.28.100 with SMTP id a4mr88obh.28.1388258473161; Sat, 28 Dec 2013 11:21:13 -0800 (PST) In-Reply-To: <186E0927-C962-4E34-AED0-E7509DD1F0A0@gmail.com> X-Original-Sender: bigotp@acm.org 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:8279 Archived-At: ------=_Part_1548_9020491.1388258472691 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Friday, December 27, 2013 11:01:34 PM UTC-6, Marshall wrote: > > On Dec 27, 2013, at 4:52 AM, abolz...@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= =20 > =93used to point at something=94 > and an empty string view =93that never pointed at anything=94 is a use ca= se to=20 > be discouraged, rather than > something that should be enshrined in the standard. > -1 ; I think it's an obvious and valuable feature. 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=20 > pointer is misguided. > > if sv.size () =3D=3D 0 or sv.empty () [same thing], there is nothing that= you=20 > can do with sv.data() > (except compare it to null, and that doesn=92t tell you anything useful). > My understanding (which I'd like confirmed) is that sv.data() is still=20 useful as it provides a valid position within the referenced object, which= =20 might be referenced by other string_view instances or in its native form. Thus, for example, a function object conforming to the delimiters interface= =20 documented at=20 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3593.html#delimite= rs=20 might return a zero-length string to denote a zero-length delimiter (e.g.,= =20 the position following a period in an English sentence). In this case it= =20 is the value of sv.data() that tells the caller where the delimited=20 sequence ends and the next sequence begins. =20 > > 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=20 > string_view return a value of 1 from data(). > > As I understand it there is no expression that can legitimately dereference= =20 that pointer, so it sounds like a clean solution to the problem. Peter --=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/. ------=_Part_1548_9020491.1388258472691 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Friday, December 27, 2013 11:01:34 PM UTC-6, Marsha= ll wrote:
On Dec 27, 2013, at 4:52 AM, abolz...@gmail.com wrote:

=

Is there a reason why string_view is not nullable?

<= div>Nullable here means default constructed or constructed from a null= ptr
(and a zero length). Then adding a is_null() (or null()) memb= er
function which can then be used to distinguish the string_view= from an
empty string.

i t= hink that attempting to distinguish between an empty string_view that =93us= ed to point at something=94
and an empty string view =93that neve= r pointed at anything=94 is a use case to be discouraged, rather than
=
something that should be enshrined in the standard.

-1 ; I think it's an obvious and valuable feature.

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

I disagree here with the proposal as currently written.<= /div>
I believe that the requirement that data() always return a n= on-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 yo= u anything useful).

My understanding (whic= h I'd like confirmed) is that sv.data() is still useful as it provides a va= lid position within the referenced object, which might be referenced by oth= er string_view instances or in its native form.

Thus, for example, a= function object conforming to the delimiters interface documented at http:= //www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3593.html#delimiters mi= ght return a zero-length string to denote a zero-length delimiter (e.g., th= e position following a period in an English sentence).  In this case i= t is the value of sv.data() that tells the caller where the delimited seque= nce ends and the next sequence begins.

 
An empty string view need not point *anywhere*, or have any da= ta behind it.

=97 Marshall

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


As I understan= d it there is no expression that can legitimately dereference that pointer,= so it sounds like a clean solution to the problem.

Peter
<= /div>

--
 
---
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>.
------=_Part_1548_9020491.1388258472691-- .