220 8605 <52d6c23b.6f8a440a.74c7.1675@mx.google.com> article Path: news.gmane.org!not-for-mail From: "=?utf-8?B?YmlsbHkub25lYWxAZ21haWwuY29t?=" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Wed, 15 Jan 2014 09:15:36 -0800 Lines: 173 Approved: news@gmane.org Message-ID: <52d6c23b.6f8a440a.74c7.1675@mx.google.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_0_1389806136045" X-Trace: ger.gmane.org 1389806139 16639 80.91.229.3 (15 Jan 2014 17:15:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 15 Jan 2014 17:15:39 +0000 (UTC) To: "=?utf-8?B?c3RkLXByb3Bvc2Fscw==?=" Original-X-From: std-proposals+bncBDKLBLVE6ADBBP4E3OLAKGQEO5MZG4A@isocpp.org Wed Jan 15 18:15:46 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 1W3U48-0008Km-BP for gclcip-std-proposals@m.gmane.org; Wed, 15 Jan 2014 18:15:44 +0100 Original-Received: by mail-ie0-f198.google.com with SMTP id tp5sf7048553ieb.1 for ; Wed, 15 Jan 2014 09:15:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:to:from:subject:date:mime-version :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=cKInyR6qPgd6/1t9lCZfqmbHwSOC4n3UmZx5crqjC68=; b=A9sDoqf1OHiuZ6a1VXxSlc2lGD1UiuB5df+x51vHgeAcLFnmRUe/p9V6Y4F3muHu7j Pnau8RhUnij7HGXc7nAwzSuKggvuZHoqU99P0EQM1F1YyPSLPKyCl/BuX4lvNxjiGuLp H1ZKo3H+EwUljwTrqdWgWvZaiLPQ+GzM3LU+wYhAhc8cPFRSWPfOt3IHsqP8TqrWxyPL PG7wIds9U4336vwAYGpvx0AWQjCeXJb2BEChKeQiXadV8TsBYLpMZj1RKb4QoX7qjudg PCOqYlEPLlNOsGhj0jj8q4SiDdB4NFO6Thsc7rdQpE9CJtHDJlscJfRBlM3PUd4UsUvT FJLg== X-Gm-Message-State: ALoCoQmScAScbzHkkv6seB4mIdSah3PCtSsaHwrGL4YOYKsiKCWRbX3Q7FhtSxVin++Xjtwen4OL X-Received: by 10.182.112.231 with SMTP id it7mr1253454obb.22.1389806143454; Wed, 15 Jan 2014 09:15:43 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.88.100 with SMTP id bf4ls664767qeb.1.gmail; Wed, 15 Jan 2014 09:15:42 -0800 (PST) X-Received: by 10.224.132.133 with SMTP id b5mr6516405qat.61.1389806142946; Wed, 15 Jan 2014 09:15:42 -0800 (PST) Original-Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [2607:f8b0:400e:c03::234]) by mx.google.com with ESMTPS id t7si6234986qar.59.2014.01.15.09.15.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 09:15:42 -0800 (PST) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:400e:c03::234 as permitted sender) client-ip=2607:f8b0:400e:c03::234; Original-Received: by mail-pa0-f52.google.com with SMTP id kx10so1422470pab.11 for ; Wed, 15 Jan 2014 09:15:40 -0800 (PST) X-Received: by 10.66.145.166 with SMTP id sv6mr4187448pab.31.1389806140763; Wed, 15 Jan 2014 09:15:40 -0800 (PST) Original-Received: from [192.168.1.121] (c-98-247-120-46.hsd1.wa.comcast.net. [98.247.120.46]) by mx.google.com with ESMTPSA id qp15sm9362737pbb.2.2014.01.15.09.15.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Jan 2014 09:15:39 -0800 (PST) X-Original-Sender: billy.oneal@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:400e:c03::234 as permitted sender) smtp.mail=billy.oneal@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:8605 Archived-At: ------=_Part_0_1389806136045 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline It should be discouraged because we don't want to have to write null checks= in every function under the sun; it is about preventing callers from suppl= ying unexpected results. string const & isn't allowed to be null; string_view shouldn't either. Sent from a touchscreen. Please excuse the brevity and tpyos. ----- Reply message ----- From: "Olaf van der Spek" To: Subject: [std-proposals] string_view::is_null() Date: Wed, Jan 15, 2014 4:20 AM On Saturday, December 28, 2013 6:59:37 PM UTC+1, Jeffrey Yasskin wrote:i th= ink that attempting to distinguish between an empty string_view that =E2=80= =9Cused to point at something=E2=80=9D and an empty string view =E2=80=9Cthat never pointed at anything=E2=80=9D i= s a use case 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.=20 if sv.size () =3D=3D 0 or sv.empty () [same thing], there is nothing that y= ou can do with sv.data() (except compare it to null, and that doesn=E2=80=99t tell you anything usef= ul). The thing is, if nullptr is a possible return value for data(), people do s= tart using it to convey information. If they get a null out exactly when th= ey put a null in, it is telling them something useful. The only way to "dis= courage" 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. In some cases being able to distinguish between null and empty is required.= string_view could easily support this distinction, what's the reason it sh= ould be discouraged? optional is an obvious suggestion but that increases code comp= lexity at the call site when the distinction is not required. --=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/. --=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_0_1389806136045 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
It sh= ould be discouraged because we don't want to have to write null checks in e= very function under the sun; it is about preventing callers from supplying = unexpected results.

string const & isn't allow= ed to be null; string_view shouldn't either.

Sent = from a touchscreen. Please excuse the brevity and tpyos.

----- Reply message -----
From: "Olaf van der Spek&= quot; <olafvdspek@gmail.com>
To: <std-proposals@isocpp.org><= br>Subject: [std-proposals] string_view::is_null()
Date: Wed, Jan 15, 20= 14 4:20 AM

On Saturday, December 28, 2013 6= :59:37 PM UTC+1, Jeffrey Yasskin wrote:
i think that attempt= ing to distinguish between an empty string_view that =E2=80=9Cused to point= at something=E2=80=9D
and an empty string view =E2=80=9Cthat never pointed at anything=E2=80= =9D is a use case to be discouraged, rather than
something that s= hould be enshrined 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. 

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=E2=80=99t tell you anything= useful).

The thing is, if null= ptr is a possible return value for data(), people do start using it to conv= ey 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 mak= e it never happen. If we let string_view::data() pass through null, we're e= nshrining the use you don't like in the standard.
 
In some cases being ab= le to distinguish between null and empty is required. string_view could eas= ily support this distinction, what's the reason it should be discouraged?

optional<string_view> is an obvious suggestio= n but that increases code complexity at the call site when the distinction = is not required.

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

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