220 8702 <52DC3ED7.9070707@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 22:08:39 +0100 Lines: 156 Approved: news@gmane.org Message-ID: <52DC3ED7.9070707@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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------010900020006080609010601" X-Trace: ger.gmane.org 1390165710 31586 80.91.229.3 (19 Jan 2014 21:08:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 21:08:30 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC6ONSXJ54LBBU756CLAKGQEKBD4RLQ@isocpp.org Sun Jan 19 22:08:36 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 1W4zbg-0002Py-ID for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 22:08:36 +0100 Original-Received: by mail-ea0-f197.google.com with SMTP id b10sf9959386eae.8 for ; Sun, 19 Jan 2014 13:08: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=Sx9gTq9ssgPTjWfgnxNbnkIhIpju3HAmvk2lFOtfdHs=; b=j7gG3N7/VmPxSgKAb8OqCu0lP+6/6TJh6YEet6N84bAXKz9NpqY/jDccObRLY3jFEC QXFEeU10sN6R4PzBdOeAYHWQ+3E5un1Dqm/K6PLfLCHLMDUorSzUq++WHHuZHmfAll0Z aBA25lozr0EOnNa5AtzC/U6CkE/ptVP0ap0DaG+0gfCfAyOtjxDywUGeATtVlq29+p+O zPFafPBuXiivigDNsdOAHJfwq5oUaQX0g291wwq2kqznpSO8eLprw0GVrDgXGfEUNat3 X5uu67DIPyou3IIVDy8AvZMUYS9AfDuxJM1x4NjyH2+xoiqaYottBVi6it7M1kbPW6Qz PZtA== X-Gm-Message-State: ALoCoQnU+NhjC/oLNrPg6QmiPkVaok6kHtKEa50UHxuW4mYTnRNV/aJBpMUyL26VO17+Y+OpD6po X-Received: by 10.180.205.168 with SMTP id lh8mr4986647wic.4.1390165716101; Sun, 19 Jan 2014 13:08:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.180.11.41 with SMTP id n9ls381603wib.5.gmail; Sun, 19 Jan 2014 13:08:35 -0800 (PST) X-Received: by 10.14.98.129 with SMTP id v1mr14139834eef.5.1390165715296; Sun, 19 Jan 2014 13:08: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 h9si10422580eev.210.2014.01.19.13.08.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 19 Jan 2014 13:08: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 3f6pX2728Qz4KK2f for ; Sun, 19 Jan 2014 22:08:34 +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 3f6pX24lRCzbbgJ for ; Sun, 19 Jan 2014 22:08:34 +0100 (CET) Original-Received: from [192.168.42.4] ([192.168.42.4]) by www.knejp.de ; Sun, 19 Jan 2014 22:08:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: <53d0e0c3-7eee-4853-886d-624bf4b22fb4@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:8702 Archived-At: This is a multi-part message in MIME format. --------------010900020006080609010601 Content-Type: text/plain; charset=UTF-8; format=flowed > 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. 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. > 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. > 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/. --------------010900020006080609010601 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 an "optional<string_view>"? 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.

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.
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.
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)
{
=C2=A0 if (s =3D=3D "abc= ") {}
=C2=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 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<string_view>. 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 &= 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>.
--------------010900020006080609010601-- .