220 8678 <52da1495.6890ec0a.4992.6c0a@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: Fri, 17 Jan 2014 21:43:48 -0800 Lines: 150 Approved: news@gmane.org Message-ID: <52da1495.6890ec0a.4992.6c0a@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_1390023828285" X-Trace: ger.gmane.org 1390023825 20640 80.91.229.3 (18 Jan 2014 05:43:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 18 Jan 2014 05:43:45 +0000 (UTC) To: "=?utf-8?B?c3RkLXByb3Bvc2Fscw==?=" Original-X-From: std-proposals+bncBDKLBLVE6ADBBFVJ5CLAKGQEPDLB7NI@isocpp.org Sat Jan 18 06:43:52 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4OhD-0005JG-Vz for gclcip-std-proposals@m.gmane.org; Sat, 18 Jan 2014 06:43:52 +0100 Original-Received: by mail-ob0-f198.google.com with SMTP id wp4sf442985obc.5 for ; Fri, 17 Jan 2014 21:43:50 -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=cvlah20AkulF9wsotH3B5Nr89QZaH2qUFQtYCiDc8tI=; b=ZkKKzO/otCPUl/5QQa3DdI5FYsxlDUzz55Gm0X2fMcJM3ED/CYBSZYAFq73g0/G10m oAGF8XaBmeEdwHUM4D0zUMQ9iZD+k8g5NY5hxF8FjbQTkLnMX9m9hzykf7T/fRfydClr 6K+dv0G1KemaDVzKuwNvJAYvbyZWuBsAO5ebbwQYzDCzVI61HuVfFeKvIjivT8V43m6Y MADgf0QXl/ff31ize/4Bmi90nFr6D2muKhupiRmKKQPPw1GGGchkAzgDunggw0Kb8+PF 6+RYMkRgZ9thlCexNm+GeyNfMB6kZzhUV2PVp/9AVeZgvzBK2wghLg9P26IYKteF+5cS XGMQ== X-Gm-Message-State: ALoCoQmc7nKNsng2uAurkL7z5EjDIN/JgrbfC567XL437MPQVdqTkfDUaJAEVHl36JQ3k7Hjc8Hz X-Received: by 10.182.24.5 with SMTP id q5mr2211595obf.23.1390023830712; Fri, 17 Jan 2014 21:43:50 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.26.195 with SMTP id 61ls607591qgv.19.gmail; Fri, 17 Jan 2014 21:43:50 -0800 (PST) X-Received: by 10.236.0.34 with SMTP id 22mr5499537yha.24.1390023830253; Fri, 17 Jan 2014 21:43:50 -0800 (PST) Original-Received: from mail-yh0-x22b.google.com (mail-yh0-x22b.google.com [2607:f8b0:4002:c01::22b]) by mx.google.com with ESMTPS id f25si18254284yho.203.2014.01.17.21.43.50 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 21:43:50 -0800 (PST) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4002:c01::22b as permitted sender) client-ip=2607:f8b0:4002:c01::22b; Original-Received: by mail-yh0-f43.google.com with SMTP id z20so262070yhz.30 for ; Fri, 17 Jan 2014 21:43:50 -0800 (PST) X-Received: by 10.236.159.8 with SMTP id r8mr5483105yhk.63.1390023830106; Fri, 17 Jan 2014 21:43:50 -0800 (PST) Original-Received: from [2601:8:9780:880:a0f2:6267:e8ed:ef18] ([2601:8:9780:880:a0f2:6267:e8ed:ef18]) by mx.google.com with ESMTPSA id m68sm22592028yhj.22.2014.01.17.21.43.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 17 Jan 2014 21:43:49 -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:4002:c01::22b 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:8678 Archived-At: ------=_Part_0_1390023828285 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline No, it does not. The empty string can just be an extern char *, and put in = a single TU. If we want to allow string view to be null, it should just be what you get = when you construct a string view from nullptr_t or default construct one. P= assing (0, 0) should be an empty string, not null. Otherwise, it becomes di= fficult to turn empty strings in many conditions into string_view s. For in= stance, creating a string view from a COM BSTR becomes non-trivial, because= a null BSTR is semantically empty, not null. I still think if you want optional semantics that you should use optional, = because it clearly defines what an API accepts. Otherwise people may be sur= prised when different behavior occurs that isn't easily discernable from th= e function's signature. (But if they can be treated as empty most of the time my opinion moves from= violent hatred to mere dislike :) ) Sent from a touchscreen. Please excuse the brevity and tpyos. ----- Reply message ----- From: "Marshall Clow" To: Subject: [std-proposals] string_view::is_null() Date: Fri, Jan 17, 2014 8:19 PM On Jan 17, 2014, at 6:13 PM, Miro Knejp wrote: >>=20 >> - both of these methods are impossible if the presumptions stated above = "begin() should never return nullptr" and "we don't need a special is_null(= )". Well, not entirely. Of course you could create some bogus object and us= e its address instead of nullptr. >>=20 > Why not set the string_view to "" in the default constructor? I believe that this is the current proposal. However, this requires creating a global variable (which some implementatio= ns will put in the code segment) for each default constructed string_view (= yes, some implementations will merge them together in the same translation = unit). =E2=80=94 Marshall --=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_1390023828285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
No, it does not. The empty string can just be an extern= char *, and put in a single TU.

If we want to all= ow string view to be null, it should just be what you get when you construc= t a string view from nullptr_t or default construct one. Passing (0, 0) sho= uld be an empty string, not null. Otherwise, it becomes difficult to turn e= mpty strings in many conditions into string_view s. For instance, creating = a string view from a COM BSTR becomes non-trivial, because a null BSTR is s= emantically empty, not null.

I still think if you = want optional semantics that you should use optional, because it clearly de= fines what an API accepts. Otherwise people may be surprised when different= behavior occurs that isn't easily discernable from the function's signatur= e.

(But if they can be treated as empty most of th= e time my opinion moves from violent hatred to mere dislike :) )
=
Sent from a touchscreen. Please excuse the brevity and tpyos= ..

----- Reply message -----
From: "= Marshall Clow" <mclow.lists@gmail.com>
To: <std-proposals@= isocpp.org>
Subject: [std-proposals] string_view::is_null()
Date: = Fri, Jan 17, 2014 8:19 PM

On Jan 17, 2014, at 6:13 PM, Miro Knejp <miro=
@knejp.de> wrote:

>>=20
>> - both of these methods are impossible if the presumptions stated =
above "begin() should never return nullptr" and "we don't need a special is=
_null()". Well, not entirely. Of course you could create some bogus object =
and use its address instead of nullptr.
>>=20
> Why not set the string_view to "" in the default constructor?

I believe that this is the current proposal.

However, this requires creating a global variable (which some implementatio=
ns will put in the code segment) for each default constructed string_view (=
yes, some implementations will merge them together in the same translation =
unit).

=E2=80=94 Marshall


--=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-proposals/=
..

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