220 8699 <53d0e0c3-7eee-4853-886d-624bf4b22fb4@isocpp.org> 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 12:31:45 -0800 (PST) Lines: 173 Approved: news@gmane.org Message-ID: <53d0e0c3-7eee-4853-886d-624bf4b22fb4@isocpp.org> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_203_8166438.1390163505400" X-Trace: ger.gmane.org 1390163508 7275 80.91.229.3 (19 Jan 2014 20:31:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 19 Jan 2014 20:31:48 +0000 (UTC) Cc: gornishanov@gmail.com, gornishanov@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCAJPLFFWYPBBMXM6CLAKGQEUDZ3RQY@isocpp.org Sun Jan 19 21:31:52 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qe0-f72.google.com ([209.85.128.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W4z23-0007Vu-Cl for gclcip-std-proposals@m.gmane.org; Sun, 19 Jan 2014 21:31:47 +0100 Original-Received: by mail-qe0-f72.google.com with SMTP id 5sf10865918qeb.3 for ; Sun, 19 Jan 2014 12:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=eDhAhx4Z5ZwpYpOsJcAHQeqTMtpABV4sMaUTwWdD3FM=; b=OuY+PpDJc9Agt6oec+FE3BOdnALIbzGaSo0JL5P92gd5oz0zthMClclL4/3Tj2+3JA y/NPIRfQQBFoIBZjzU4jSXj9iGtbBa0qN0WHcbHOolGdUJVZFBhMtvBDtn9VryVUS+z5 1jwcQ2TAGycJCYD25aMORY67/uyRkkKuixpdQQg15KcfJ8rxz211MWTS/SzJD+nbtBPY 8ePRhDvd+dLrzKZphh0p7WXPNAk9VzJoFOx0KSa9G7n6yylDc2Y/77BrE74oF9XgvcAV Y/KIcFQQzTgEkIovaf9hbTFvVA0VezmqUuv+ixcLPcPgfNrZvt1zgV14UbUqIuCJk4fY bmeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=eDhAhx4Z5ZwpYpOsJcAHQeqTMtpABV4sMaUTwWdD3FM=; b=FsBmRkslmT1YAOJK0EFRFwx+PdAASaKMBsAEbfpUehUrparOwQDIbhphL8DhvIFwfd KTtfspTvbEl8DQhZpJzSHmACJ2xBRXTII3ksa5uoh07C/Kqyw3KAtBI+za34/4zdvIsX MVOeN1lGOk+C/K/cipFLJXQc5Dx+Ov2p5pF8mQKz/Q5mzvP6Whk+awEr/OkkagwXUqkv RLNuHfQN4pE15UPvKm40PUzCQuRjEIrZYLYbN3PG1Ucd+IUwOZ47xopFuAgmT9vnvpQi Xjqk8oqOrs44WLzAogmTFeqgS7Pw4XE265NH8cqoI1xXtTcadEaYDEHj43qsKBc/HZLE eM1Q== X-Gm-Message-State: ALoCoQkQx8dl//OMTWOMp031LuClWjcpWq8IzNMkkBMu55zx7Bd8W7GXKWfbIRhByrnHBASpcPXg X-Received: by 10.236.19.36 with SMTP id m24mr4253176yhm.14.1390163506467; Sun, 19 Jan 2014 12:31:46 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.92.240 with SMTP id b103ls223912qge.57.gmail; Sun, 19 Jan 2014 12:31:45 -0800 (PST) X-Received: by 10.140.26.101 with SMTP id 92mr1878qgu.18.1390163505933; Sun, 19 Jan 2014 12:31:45 -0800 (PST) In-Reply-To: X-Original-Sender: abolz.lists@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:8699 Archived-At: ------=_Part_203_8166438.1390163505400 Content-Type: text/plain; charset=UTF-8 Am Sonntag, 19. Januar 2014 19:31:58 UTC+1 schrieb gorni...@gmail.com: > I did not propose using unspecialized optional. I suggested to add > specialization of optional> to string_view header. > Thus any use of optional will pick up specialized version that > can have constructors that you desire. > Ok. But an unspecialized optional is very different from a nullable string_view. And a specialized optional would be very different from an optional. I need to make sure that the specialized version is constructible from a nullptr and and then constructing a disengaged optional. Then what should template constexpr explicit optional(in_place_t, Args&&... args); Postconditions: *this is engaged. do? 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") {} } The default relational operators explicitly handle the nullness of the optional. I don't want that. I'd expect a disengaged optional is like an empty string. So I write specialized versions for these relational operators which do exactly that. That would be very confusing for general algorithms which just compare optional's. > > I think it is beneficial to not to roll nullability into > string_view. optional is The Way to make type nullable and where possible, > one can use specialized optional to add additional constructors and/or > provide more efficient implementation than default optional. > > > On Saturday, January 18, 2014 7:30:17 AM UTC-8, Alexander Bolz wrote: > >> Am Samstag, 18. Januar 2014 00:10:41 UTC+1 schrieb gorni...@gmail.com: >>> >>> What if string_view provides a specialization for >>> optional>? >>> >>> That way optional can be implemented very efficiently by >>> checking if sv.begin() == nullptr and does not consume any extra storage. >>> An extra benefit is that we have clear distinction between nullable types >>> (optional) and regular types, int, vector, string_view, etc. >>> >>> Will this solution satisfy the original poster? >>> >> >> An (unspecialized) optional is not always an option. E.g. I >> can't simply change a function like >> >> void f(char const* s) {} >> >> to >> >> void f(optional s) {} >> >> because I can no longer write f("hello"). So the specialization should be >> implicitly constructible from a char array. >> And then an optional constructed from a nullptr should be an >> uninitialized optional since there >> are no preconditions on f, I should be able to write >> f(getenv("not-an-env-var")). >> >> -- --- 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/. ------=_Part_203_8166438.1390163505400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Am Sonntag, 19. Januar 2014 19:31:58 UTC+1 schrieb gorni..= ..@gmail.com:
I did not propose using unspecialized optional. I suggested to add = specialization of optional<basic_string_view<...>> to stri= ng_view header. Thus any use of optional<string_view> will pick up sp= ecialized version that can have constructors that you desire.

Ok. But an unspecialized optional<string_= view> is very different from a nullable string_view.
And a spe= cialized optional<string_view> would be very different from an option= al<T>.

I need to make sure that the speciali= zed version is constructible from a nullptr and
and then construc= ting a disengaged optional. Then what should

template <class... Args> constexpr e= xplicit optional(in_place_t, Args&&... args);
Postconditions: *this is= engaged.

do?

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

<= div>void f(optional<string_view>= ; s)
{
<= div>  if (s =3D=3D "abc") {}
  if (s < "abc"= ) {}
}
<= div>
The default relational operators explicitly handle the n= ullness of the optional. I don't want
that. I'd expect a disengag= ed optional<string_view> is like an empty string. So I write speciali= zed
versions for these relational operators which do exactly that= .. That would be very confusing for
general algorithms which just = compare optional<T>'s.
 

I think it is= beneficial to not to roll nullability into string_view. optional is T= he Way to make type nullable and where possible, one can use specialized op= tional to add additional constructors and/or provide more efficient impleme= ntation than default optional.


On Saturday, January 18, 2= 014 7:30:17 AM UTC-8, Alexander Bolz wrote:
Am Samstag, 18. Januar 2014 00:10:41 UTC+1 schrieb gorni...@gma= il.com:
What if string_view provi= des a specialization for optional<string_view<>>?
That way optional<string_view> can be implemented very ef= ficiently by checking if sv.begin() =3D=3D nullptr and does not consume any= extra storage. An extra benefit is that we have clear distinction between = nullable types (optional<T>) and regular types, int, vector, string_v= iew, etc.

Will this solution satisfy the original = poster?

An (unspecialized) = optional<string_view> is not always an option. E.g. I can't simply&nb= sp;change a function like

void f(char const* s) {}=

to

void f(optional<st= ring_view> s) {}

because I can no longer write = f("hello"). So the specialization should be implicitly constructible from&n= bsp;a char array.
And then an optional<string_view> constru= cted from a nullptr should be an uninitialized optional since there
are no preconditions on f, I should be able to write f(getenv("not-an-en= v-var")).

--
 
---
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_203_8166438.1390163505400-- .