220 8725 article Path: news.gmane.org!not-for-mail From: Paul Tessier Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Sun, 19 Jan 2014 19:39:14 -0800 (PST) Lines: 192 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> <8E74B747-7450-41E0-8D1E-48C2D6F81535@gmail.com> <3a3d55c0-20cb-40ff-ae46-84663d21f44d@isocpp.org> <53d0e0c3-7eee-4853-886d-624bf4b22fb4@isocpp.org> <52DC3ED7.90707 07@knejp.de> <52DC5781.2070908@knejp.de> <975e038a-8ae2-48d4-ba5b-3b6d7d67cea7@isocpp.org> <52DC7DA8.9030707@knejp.de> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1689_8595788.1390189155087" X-Trace: ger.gmane.org 1390189151 31874 80.91.229.3 (20 Jan 2014 03:39:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 03:39:11 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDDYTQX56INBBY5U6KLAKGQEQA24P7I@isocpp.org Mon Jan 20 04:39:17 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W55hl-0007VM-55 for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 04:39:17 +0100 Original-Received: by mail-ie0-f199.google.com with SMTP id x13sf26756751ief.6 for ; Sun, 19 Jan 2014 19:39:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=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=Tq/ev+ZDhPTV4p82wBgQKtJY1hO+TGqOja3YdYFqkVc=; b=d5CccM10iRYg+80MLEFm9nDOrTInSnPsfuZ1b49NwPO5IYVZ6EE9tqcGffLJzCU86f OaUssWT2xuEBFqnqABuMyqJNuIFD5+ZvQyWBqWNApiyPJBDXnJdnQOhQbft+XS/ageYz 1a/Bte37jh9jRiZ3HYT+6zpzHPJ6a5H4QCbXGEW6U85OobMnvFIYE2cbrQcCadZUjLDy mpw+kekCifagqW72n/hE1hu4SAc0Rv9ycDINo4npUfimIM7jsUsgANdJ2cQAXzbdmXRK 8GcLkuVesHlGYb8zCWWqSug3DFDarzbGrk5x3cdB/5NeCCQ5n2egpdDbY1SJHS7PQca8 4PRQ== 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=Tq/ev+ZDhPTV4p82wBgQKtJY1hO+TGqOja3YdYFqkVc=; b=ipVNp+z23oVahMxPUPeUPKmjljZArLOljYMj8tRDWAbVaIMDNHfjnRcrgagxQN8r0/ 0Ubgo4YUkX4TtNJJnGoPHUmpDOC0JanuJyQM8L4lBhqFe4hMOUpNQiPbn73B6DhkNF9r h+12O6nytVhmSg7mHdUbnTBPOV/MCUhQG1eluQF8+dRt9oqytQPxPDeKZA4FCtYKgI1/ S9Jg+ai0MAy4GNM8MuIIcb0S/G1BFqQqPIoZfo03v9oiUFLt2af/iPajDnZ9gqw4m5tU vES0vSDu5pJi+jgYIVyJrPc6I6hHGz9GON/ElG7kQobPD2LW9R+wYX0axO1Uxs6k4PYg wRrg== X-Gm-Message-State: ALoCoQlhrEbshL3BGLXqHP0VWPjMBRxhLN3sltjCQRizx3h+fDe278SHJszkTvZiNy8Gx780WwXX X-Received: by 10.182.33.6 with SMTP id n6mr5886740obi.6.1390189156108; Sun, 19 Jan 2014 19:39:16 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.82.49 with SMTP id g46ls907976qgd.88.gmail; Sun, 19 Jan 2014 19:39:15 -0800 (PST) X-Received: by 10.140.109.244 with SMTP id l107mr55qgf.28.1390189155577; Sun, 19 Jan 2014 19:39:15 -0800 (PST) In-Reply-To: <52DC7DA8.9030707@knejp.de> X-Original-Sender: phernost@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:8725 Archived-At: ------=_Part_1689_8595788.1390189155087 Content-Type: text/plain; charset=UTF-8 On Sunday, January 19, 2014 8:36:40 PM UTC-5, Miro Knejp wrote: > > > > For a function like > > void print(string const& s) { > } > > there is an implicit precondition: a string can not be constructed from > a nullptr. > So you have to check this before calling. When replacing string const& > with string_view, > you just need to make the precondition explicit. Then in both cases data() > != null. > > Yes, I as author of print have the implicit precondition enforced by > std::string that it's always called with a valid string. That is something > I can rely on. That is a good thing. Changing the signature to accept > (nullable) string_view suddenly breaks this guarantee and I either have to > add asserts or some other kinds of checks and document it somewhere and > needlessly complexify every method relying on this guarantee. That is a bad > thing. And suddenly you need to create new test cases for print even though > it was working perfectly. That is also a bad thing. > How is that true. If a string_view is null, how is it not valid. All null views are empty views. No additionally complexity or coding is required. Calling other members with an empty view is for the most part undefined behaviour. If data(), begin(), etc. return null or not is irrelevant, and an arbitrary restriction. > > If you use string.data(), you can't simply replace func(string const&) > with func(string_view) > even if data() returns non-null, since data() might not be null terminated. > > void print(string const& s) { > printf("%s", s.data()); > } > > If yyou don't use data() then, well... its not important if data() > returns nullptr or not. > > If one used .data() to pass it to (const char*) methods (which should ring > a bell and make you pay *very good attention* to what you're doing) before > C++11 then it was already calling for disaster as .data() was not > guaranteed to be null terminated. Then there are the methods which take a > pointer and a length. There it doesn't matter but they might crash if > passed in null (even if the length is 0). Seen it happen more often than I > like. I always tell people to use .c_str() because it is more explicitly > stating intentions and it is backwards compatible. > > null always makes things more complicated than necessary. Just notice how > the library is evolving to gradually remove the word and value "null" from > our everyday usage. That's a good thing. Think in abstractions, not null. > Throwing null at everyone only to enable a few edge cases seems wrong. One > can always come up with situations where a nullable string_view might be > useful, as is the case with many other things deemed "bad", but in the end > it matters how common that scenario is compared to where a non-null > guarantee makes code safer, simpler and more robust. > A legacy interface's poorly handled parameters should not be used as an excuse for a design argument. -- --- 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/. ------=_Part_1689_8595788.1390189155087 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sunday, January 19, 2014 8:36:40 PM UTC-5, Miro= Knejp wrote:
=20 =20 =20


For a function like

void print(string const& s) {
}

there is an implicit precondition: a string can not be constructed from a nullptr.
So you have to check this before calling. When replacing string const& with string_view,
you just need to make the precondition explicit. Then in both cases data() !=3D null.
Yes, I as author of print have the implicit precondition enforced by std::string that it's always called with a valid string. That is something I can rely on. That is a good thing. Changing the signature to accept (nullable) string_view suddenly breaks this guarantee and I either have to add asserts or some other kinds of checks and document it somewhere and needlessly complexify every method relying on this guarantee. That is a bad thing. And suddenly you need to create new test cases for print even though it was working perfectly. That is also a bad thing.

How is that true.  If a string_view is null, how is it not valid.=   All null views are empty views.  No additionally complexity or = coding is required.  Calling other members with an empty view is for t= he most part undefined behaviour.  If data(), begin(), etc. return nul= l or not is irrelevant, and an arbitrary restriction.

If you use string.data(), you can't simply replace func(string const&) with func(string_view)
even if data() returns non-null, since data() might not be null terminated.

void print(string const& s) {
  printf("%s", s.data());
}

If yyou don't use data() then, well... its not important if data() returns nullptr or not.
If one used .data() to pass it to (const char*) methods (which should ring a bell and make you pay *very good attention* to what you're doing) before C++11 then it was already calling for disaster as .data() was not guaranteed to be null terminated. Then there are the methods which take a pointer and a length. There it doesn't matter but they might crash if passed in null (even if the length is 0). Seen it happen more often than I like. I always tell people to use .c_str() because it is more explicitly stating intentions and it is backwards compatible.
 
null always makes thing= s more complicated than necessary. Just notice how the library is evolving to gradually remove the word and value "null" from our everyday usage. That's a good thing. Think in abstractions, not null. Throwing null at everyone only to enable a few edge cases seems wrong. One can always come up with situations where a nullable string_view might be useful, as is the case with many other things deemed "bad", but in the end it matters how common that scenario is compared to where a non-null guarantee makes code safer, simpler and more robust.

A legacy interface's poorly handled parameters should not be used as an = excuse for a design argument.

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