220 8712 <52DC5781.2070908@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: Sun, 19 Jan 2014 23:53:53 +0100 Lines: 128 Approved: news@gmane.org Message-ID: <52DC5781.2070908@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050600080705010905060701" X-Trace: ger.gmane.org 1390172024 31852 80.91.229.3 (19 Jan 2014 22:53:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 22:53:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBB7VO6GLAKGQEOKQALDQ@isocpp.org Sun Jan 19 23:53:51 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ea0-f197.google.com ([209.85.215.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W51FX-0001gY-Ig for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 23:53:51 +0100 Original-Received: by mail-ea0-f197.google.com with SMTP id b10sf10084360eae.4 for ; Sun, 19 Jan 2014 14:53:51 -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=EqcCeKpCGryycIBn0EAmHAJ3x03oOD271fT74+h9aq8=; b=afz6hZh6GMNPfB7mBCSwjJY54buvJZoAAnIEu/+RFfmFVdLNUQZ3vEXULnyos1S+QK JMHtK4hY0RGb1WVbCTJnfTtQx6KI30pV092vx+P9/RO1Fufcplm20Ij+uDh3rSwX2x0o ANVcB/NmED4r6bIrVio6C+opA5fLC5VdRZC/nqt/j7s24k95mKtBbNw6GRo8igLCAxtz NcaLbcMmMWQ1c7/lR0F01LiRME4BIShyPV76c6pf5fnylfh4JYQt/wVt/AGcogSIIFjt nF66LP2bmChm1Pxogdqz0pFjHE6FyxB2MBft6jalUftJ0rXBEMzDkH+puAKDweE6m4/8 GWog== X-Gm-Message-State: ALoCoQl6q4pzWCQO+XMr3t8fV2wEiuQyj87DDgSllchegjc9nRIITKEXST1Z/OzfKCI1+tMnBkVA X-Received: by 10.112.56.100 with SMTP id z4mr6819882lbp.0.1390172031111; Sun, 19 Jan 2014 14:53:51 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.9.41 with SMTP id w9ls375085wia.50.gmail; Sun, 19 Jan 2014 14:53:50 -0800 (PST) X-Received: by 10.180.94.67 with SMTP id da3mr7547539wib.38.1390172030380; Sun, 19 Jan 2014 14:53:50 -0800 (PST) Original-Received: from mail-out.m-online.net (mail-out.m-online.net. [2001:a60:0:28:0:1:25:1]) by mx.google.com with ESMTPS id o7si6662092wiy.16.2014.01.19.14.53.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jan 2014 14:53:50 -0800 (PST) Received-SPF: neutral (google.com: 2001:a60:0:28:0:1:25:1 is neither permitted nor denied by best guess record for domain of miro@knejp.de) client-ip=2001:a60:0:28:0:1:25:1; Original-Received: from frontend1.mail.m-online.net (frontend1.mail.intern.m-online.net [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 3f6rsV05cGz3hhqn for ; Sun, 19 Jan 2014 23:53:50 +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 3f6rsT5qH8zbbcN for ; Sun, 19 Jan 2014 23:53:49 +0100 (CET) Original-Received: from [192.168.42.4] ([192.168.42.4]) by www.knejp.de ; Sun, 19 Jan 2014 23:53:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-Original-Sender: miro@knejp.de X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 2001:a60:0:28:0:1:25:1 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:8712 Archived-At: This is a multi-part message in MIME format. --------------050600080705010905060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > I just don't want to do that. I have a function like > > void f(char const* s) { > if (s == nullptr) > dothis(); > else > dothat(); > } > > and I want to replace char const* with string_view to make it accept a > std::string so I can save some std::string.c_str() > calls. > Saving some string.c_str() calls isn't a very convincing argument. Not for me at least. When I have to chose between safety/robustness or convenience the former wins. Knowing a std::string_view cannot be null just as std::string cannot be is a valuable quality of life improvement. I would assume the number of times one needs a nullable string is only a fraction of the actual uses of string_view. string_view has as far as I can remember always been described as a drop-in replacement for string. Discussing the possibility of a nullable std::string_view should equally raise a discussion about the possibility of a nullable std::string. If it is not possible to replace functions taking (const string&) with (string_view) and have the same semantics it's far less usefull and only works against the trend of making things safer and more intuitive. (const char*) methods should always ring alarm bells. -- --- 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/. --------------050600080705010905060701 Content-Type: text/html; charset=ISO-8859-1

I just don't want to do that. I have a function like

void f(char const* s) {
  if (s == nullptr)
    dothis();
  else
    dothat();
}

and I want to replace char const* with string_view to make it accept a std::string so I can save some std::string.c_str()
calls.

Saving some string.c_str() calls isn't a very convincing argument. Not for me at least. When I have to chose between safety/robustness or convenience the former wins. Knowing a std::string_view cannot be null just as std::string cannot be is a valuable quality of life improvement. I would assume the number of times one needs a nullable string is only a fraction of the actual uses of string_view.

string_view has as far as I can remember always been described as a drop-in replacement for string. Discussing the possibility of a nullable std::string_view should equally raise a discussion about the possibility of a nullable std::string. If it is not possible to replace functions taking (const string&) with (string_view) and have the same semantics it's far less usefull and only works against the trend of making things safer and more intuitive. (const char*) methods should always ring alarm bells.

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