220 8721 <52DC7DA8.9030707@knejp.de> article Path: news.gmane.org!not-for-mail From: Miro Knejp Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Mon, 20 Jan 2014 02:36:40 +0100 Lines: 172 Approved: news@gmane.org Message-ID: <52DC7DA8.9030707@knejp.de> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------060100090409090202030703" X-Trace: ger.gmane.org 1390181791 24721 80.91.229.3 (20 Jan 2014 01:36:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jan 2014 01:36:31 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBBJH36GLAKGQEUR7FWAI@isocpp.org Mon Jan 20 02:36:37 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wi0-f197.google.com ([209.85.212.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W53n3-0007F4-C7 for gclcip-std-proposals@m.gmane.org; Mon, 20 Jan 2014 02:36:37 +0100 Original-Received: by mail-wi0-f197.google.com with SMTP id m19sf870159wiv.0 for ; Sun, 19 Jan 2014 17:36:36 -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:date:from:user-agent:mime-version:to :subject:references:in-reply-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=E2rddNl5uCFymdwKTtmfstOGE6cnrK2BVaJPQ0WDMhk=; b=B+ns4UuuQmH+z5qkbghZzLcjkHX8WSIoEiTmbHaSG5p6wF5ZgBiMWrsaYJselz2kkt tASaAQkFEDezOApqj2GaKr2ECKZ5TsRN+thzA9t8XmJicgBE/XxwJIbgzOHMiKwtwh3k T3FsnITKJuZXFkj/wTdxHx55IcQA7TlTTrqUjTK0ps2M6ua4TqOGRmYW9sgOddcWMx92 tBr/GN69RCTNAY/Ys/YFGZZ3hmCwgdAd9wUBYs7W2538eLsIJ8EkdHN+Nl7XSIHwv5cs Kx81mKWryzsvB+C4GEi5YuUb5IrN58GKSgio4idszDgvwd8aMwyl5NkHdDIdSaGZW8Gh 0uiQ== X-Gm-Message-State: ALoCoQmA628YIJq8tL+ql/25h2XeTIO/19PM0Qc6yN10ew24cV1YXKSYXe11iA8OJAcv11/3UH4Z X-Received: by 10.152.42.179 with SMTP id p19mr7016874lal.3.1390181796613; Sun, 19 Jan 2014 17:36:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.184.52 with SMTP id er20ls76875wic.33.canary; Sun, 19 Jan 2014 17:36:35 -0800 (PST) X-Received: by 10.14.104.7 with SMTP id h7mr14968726eeg.48.1390181795956; Sun, 19 Jan 2014 17:36:35 -0800 (PST) Original-Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.9]) by mx.google.com with ESMTPS id g41si35992020eem.57.2014.01.19.17.36.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jan 2014 17:36:35 -0800 (PST) Received-SPF: neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of miro@knejp.de) client-ip=212.18.0.9; Original-Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3f6wTH53YRz4KK3f for ; Mon, 20 Jan 2014 02:36:35 +0100 (CET) Original-Received: from www.knejp.de (ppp-188-174-14-30.dynamic.mnet-online.de [188.174.14.30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with SMTP id 3f6wTH3H2jzbbch for ; Mon, 20 Jan 2014 02:36:35 +0100 (CET) Original-Received: from [192.168.42.4] ([192.168.42.4]) by www.knejp.de ; Mon, 20 Jan 2014 02:36:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <975e038a-8ae2-48d4-ba5b-3b6d7d67cea7@isocpp.org> X-Original-Sender: miro@knejp.de X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 212.18.0.9 is neither permitted nor denied by best guess record for domain of miro@knejp.de) smtp.mail=miro@knejp.de 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:8721 Archived-At: This is a multi-part message in MIME format. --------------060100090409090202030703 Content-Type: text/plain; charset=UTF-8; format=flowed > > 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. > > 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. -- --- 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/. --------------060100090409090202030703 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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.

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) {
=C2=A0 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.

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