220 8708 article Path: news.gmane.org!not-for-mail From: Alexander Bolz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: string_view::is_null() Date: Sun, 19 Jan 2014 22:56:45 +0100 Lines: 298 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.9070707@knejp.de> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=90e6ba3fcd17f137df04f059d99d X-Trace: ger.gmane.org 1390168604 29795 80.91.229.3 (19 Jan 2014 21:56:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 21:56:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCAJPLFFWYPBBHUU6GLAKGQEUJJMX6A@isocpp.org Sun Jan 19 22:56:52 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f197.google.com ([209.85.214.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W50MK-0008Ik-E7 for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 22:56:48 +0100 Original-Received: by mail-ob0-f197.google.com with SMTP id gq1sf17429095obb.4 for ; Sun, 19 Jan 2014 13:56:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from: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=1BpeLO2SgNtbhiBDlRLRRYgk9U0yvDUqxljZK/QRpNo=; b=RdKBsA+P4JLJIuPXp/uVA49E1rgJ/5pA44znA0b+Ve5FZ8xvaTVskKlm5aeUt0gxTU 3coAr3eqZyy8ORctrQB1Szd4rtoXKshupdP6Bcnq1MOwV5e7Z2J+OnibCwViyB2v1Qzn 7LejSWjs5eY4INbGlFP76REFmCJE+05CrrBV96W1NAQhfQ23INQ9zd+lYus7Usigkupx 1+csfBh0IXllni4/IAELulBRf1P9KsVLEfP87Hv6s2yobWbod6TDxoK9VrpLuTVCoB8a N5T+n/UZCPgKUiXg012WPRQnFBs+0CC4BMItO+ukUqJsNNInVtSXGYPVXf2KhiV6F7OK XDcA== X-Gm-Message-State: ALoCoQkmHhJ30ang9Ro7zM8Ckj5Wi/vBVTaWBcnF9ZmycHADPJB6aOVEaaW74uHg9tZwcoHB83/e X-Received: by 10.42.70.142 with SMTP id f14mr4691555icj.6.1390168607216; Sun, 19 Jan 2014 13:56:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.81.16 with SMTP id e16ls878958qgd.63.gmail; Sun, 19 Jan 2014 13:56:46 -0800 (PST) X-Received: by 10.236.158.226 with SMTP id q62mr14203894yhk.2.1390168606582; Sun, 19 Jan 2014 13:56:46 -0800 (PST) Original-Received: from mail-ig0-x242.google.com (mail-ig0-x242.google.com [2607:f8b0:4001:c05::242]) by mx.google.com with ESMTPS id j50si19115760yhc.100.2014.01.19.13.56.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 19 Jan 2014 13:56:46 -0800 (PST) Received-SPF: pass (google.com: domain of abolz.lists@gmail.com designates 2607:f8b0:4001:c05::242 as permitted sender) client-ip=2607:f8b0:4001:c05::242; Original-Received: by mail-ig0-f194.google.com with SMTP id m12so973628iga.1 for ; Sun, 19 Jan 2014 13:56:46 -0800 (PST) X-Received: by 10.42.65.73 with SMTP id k9mr2564970ici.44.1390168606061; Sun, 19 Jan 2014 13:56:46 -0800 (PST) Original-Received: by 10.50.119.40 with HTTP; Sun, 19 Jan 2014 13:56:45 -0800 (PST) In-Reply-To: <52DC3ED7.9070707@knejp.de> X-Original-Sender: abolz.lists@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of abolz.lists@gmail.com designates 2607:f8b0:4001:c05::242 as permitted sender) smtp.mail=abolz.lists@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:8708 Archived-At: --90e6ba3fcd17f137df04f059d99d Content-Type: text/plain; charset=ISO-8859-1 2014/1/19 Miro Knejp > > Ok. But an unspecialized optional is very different from a > nullable string_view. > And a specialized optional would be very different from an > optional. > > What is the difference between a "nullable string_view" and an > "optional"? Not in terms of syntax but semantics. That's what > must be the same. Both give you means of marking the string_view as *null* > and both cause errors/UB if accessing such a string. > Yes, and that's almost the only thing both have in common. With "nullable" I mean that it should be possible to construct a string_view from a nullptr and -- for consistency -- data() should be allowed to return nullptr. Any operation on string_view would assume that a null string_view is equal to an empty string_view. The current proposal requires data != null. Ok. But IMHO there is no reason for this. It just restricts the cases where a string_view would be useful. Now the caller has to do a null check even if a function could handle null pointers. > > If done properly the only difference between optional and > optional is sizeof() by optimizing away a bool member and use > .data() == nullptr for determining whether the optional is engaged or not. > As long as string_view does not accept null this distinction can be made. > If data() == nullptr ever returns true, string_view is already nullable. > > I need to make sure that the specialized version is constructible from > a nullptr and > and then constructing a disengaged optional. > > Do the null check before constructing the optional. If the string_view > constructor does not accept nullptr neither does > optional(in_place_t, ...). Just like for any other T. > 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. > > What should the relational operators of this specialization look like? I > would like to be > able to write something like > > void f(optional s) > { > if (s == "abc") {} > if (s < "abc") {} > } > > Since it's an optional you still have to use it like an optional. If > "s" is disengaged both comparsions return false, which is correct and I > would expect the same for a null string_view. Just like with any other T. > > Instead of using "if(s.data())" use "if(s)" or "if(!s)" to check for null. > > I don't see why there should be a difference between specialized and > unspecialized optional. I also don't see how it is different > from a "null string_view". As far as I can see the semantics are > equivalent. As long as string_view does not accept nullptr the > specialization is nothing but a sizeof() optimizing implementation detail. > > -- > > --- > 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/. > -- Alex -- --- 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/. --90e6ba3fcd17f137df04f059d99d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2014/1/19 Miro Knejp = <miro@knejp.de>
=20 =20 =20

Ok. But an unspecialized optional<string_view> is very different from a nullable string_view.
And a specialized optional<string_view> would be very different from an optional<T>.
What is the difference between a "nullable string_view" and a= n "optional<string_view>"? Not in terms of syntax but sem= antics. That's what must be the same. Both give you means of marking the string_view as *null* and both cause errors/UB if accessing such a string.

Yes, and that'= s almost the only thing both have in common. With "nullable" I me= an that it
should be possible to construct a string_view from a nullptr and -- for = consistency -- data()
should be allowed to return nullptr. Any operation on string_view would ass= ume that a null
string_view is equal to an empty string_view.=

The current proposal requires data !=3D null. Ok. But IMHO = there is no reason for this. It just
restricts the cases where a string_view would be useful.

Now the caller has to do a null check even if a function could handle null = pointers.
=A0

If done properly the only difference between optional<T> and optional<string_view> is sizeof() by optimizing away a bool member and use .data() =3D=3D nullptr for determining whether the optional is engaged or not. As long as string_view does not accept null this distinction can be made.

If data() =3D=3D nullptr ever returns true, string_view is already nul= lable.

=A0

I need to make sure that the specialized version is constructible from a nullptr and
and then constructing a disengaged optional.
Do the null check before constructing the optional. If the string_view constructor does not accept nullptr neither does optional<string_view>(in_place_t, ...). Just like for any other T.

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

=A0 if (s =3D=3D nullptr)
=A0 =A0 dothis();
=A0 else=
= =A0 =A0 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.

=A0

What should the relational operators of this specialization look like? I would like to be
able to write something like

void f(optional<string_view> s)
{
=A0 if (s =3D=3D "a= bc") {}
=A0 if (s < "abc= ") {}
}
Since it's an optional<T> you still have to use it like an optional<T>. If "s" is disengaged both comparsions retu= rn false, which is correct and I would expect the same for a null string_view. Just like with any other T.

Instead of using "if(s.data())" use "if(s)" or &quo= t;if(!s)" to check for null.

I don't see why there should be a difference between specialized an= d unspecialized optional<string_view>. I also don't see how it is different from a "null string_view". As far as I can see t= he semantics are equivalent. As long as string_view does not accept nullptr the specialization is nothing but a sizeof() optimizing implementation detail.

--
=A0
---
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/gro= up/std-proposals/.



--
=
Alex

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