220 20626 <6a0ad653-4764-483b-afb5-74d444be15d9@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Null -conditional and -coalescing operators Date: Tue, 22 Sep 2015 10:15:58 -0700 (PDT) Lines: 151 Approved: news@gmane.org Message-ID: <6a0ad653-4764-483b-afb5-74d444be15d9@isocpp.org> References: <4c3e2ee7-2159-4e93-a439-7d5c94c38c9c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6521_1704363543.1442942158518" X-Trace: ger.gmane.org 1442942165 15134 80.91.229.3 (22 Sep 2015 17:16:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 22 Sep 2015 17:16:05 +0000 (UTC) Cc: joewoodbury@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBT4ZQ2YAKGQEAQQG3XA@isocpp.org Tue Sep 22 19:16:02 2015 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 1ZeRAf-00027Q-Fn for gclcip-std-proposals@m.gmane.org; Tue, 22 Sep 2015 19:16:01 +0200 Original-Received: by obcfb16 with SMTP id fb16sf21499773obc.1 for ; Tue, 22 Sep 2015 10:15:59 -0700 (PDT) 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:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=K9C8gkqNA3U0DXE0Q/EWb6yIDJjt3pA9gegjtCHWZss=; b=w9HGt1P+0SFF/QrFh1lKSfsU8wUju9ExhpxDPip2ezESBNGpWq/BjX8eQxxCvrIiyG 26P05n87ZceiVLm5mHBsZG5gxDKEJf1RYnLAkmKMKLaLxNwMWi0R2N/H1xmaJk3kA+jt DMuk666Jm+ksRpcJloYUZN64SpeZoqHkunpyGfEolLy7DnMJzt0f9Xmp7PxAE/YlvDHt yn1I9LaIKyHawQJXL0Em5a3jyvPhG1k1UXv8+MCd911V3tQ+KSMvREHJPi4/GVTZ2aiy uYEJ2hnrOvOboD8Fqnnms1bdp6V30EFyhEN2D3sJFnjD1Jt9jKIrYIcdOjJU7aIqiqpr vKIg== 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:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=K9C8gkqNA3U0DXE0Q/EWb6yIDJjt3pA9gegjtCHWZss=; b=lu0Y9+D2vZOksRuq9ixMJoJ3lsBNdgpoy/MOfgdfSzdxe8YJikWJ3MW4bcOjOF2lPA C6+i0AiYPZUumvrT9SKYOUuLjOl/0z4GI+3ADY2+i/r6VQxqQRCxK6Qa/oq14R2xavyB gAykgi+eTk9aCCy0b8HTi+i/0WG1NHzaos5XmirP+vFTz3WeVLcF9AcAAPwHMViLcHWR c62A+Rb9y6pmScbZgL7wBPswPbnis3Ktd5XGU401NDOQL+03mKNkHmVqcX0+b9H4GHns jpBKdELkWj/FUJqZ6494SradBTmm4/HBU72LjdRVG5S+jC6nIHmWvv9+YQs+8yqGVH8f FTzA== X-Gm-Message-State: ALoCoQmxIrKVWf5pPBTVE5V/xGLEEhivNI9VhTtBNJRSGdvEe7AQwmE3jkc20a/af6XMbrBsVdxI X-Received: by 10.107.10.15 with SMTP id u15mr27389107ioi.22.1442942159786; Tue, 22 Sep 2015 10:15:59 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.122.39 with SMTP id lp7ls209461igb.42.gmail; Tue, 22 Sep 2015 10:15:59 -0700 (PDT) X-Received: by 10.50.13.38 with SMTP id e6mr206528igc.5.1442942159024; Tue, 22 Sep 2015 10:15:59 -0700 (PDT) In-Reply-To: <4c3e2ee7-2159-4e93-a439-7d5c94c38c9c@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:20626 Archived-At: ------=_Part_6521_1704363543.1442942158518 Content-Type: multipart/alternative; boundary="----=_Part_6522_697935313.1442942158518" ------=_Part_6522_697935313.1442942158518 Content-Type: text/plain; charset=UTF-8 On Tuesday, September 22, 2015 at 1:03:47 PM UTC-4, joewo...@gmail.com wrote: > > Checking for null and then doing one thing is a common task. > null-conditional and null-coalescing operators would be a nice solution. > > For example, given the following pointer: > > unique_ptr connection; > > This may happen: > > if (connection) > { > connection->sendMessage(msg); > } > > A nice alternative would be: > > connection ?: connection->SendMessage(msg); > Or you could have just written: if(connection) connection->SendMessage(msg); That requires only one or two extra keystrokes. Both of these are restricted to single lines to be executed. I've had situations where if anything resolves to false on the left, this > ?: would be useful. > > Or even better, to carry the concept forward: > > connection?->SendMessage(msg); > Ultimately, I don't think good coding practices make this as necessary as you let on. Most of the time, if you have a pointer, you know it's valid. It was checked for validity when you received it, and you don't want to constantly check to see if the thing that was valid before remains valid now. We don't need to use up precious syntax for a relatively infrequent case. Likewise: > > bool success = connection ?: false; > Also easily done like this: auto success = bool{connection}; `explicit operator bool` will be called here, since you explicitly asked for it. -- --- 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_6522_697935313.1442942158518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, September 22, 2015 at 1:03:47 PM UTC-4, joewo.= ...@gmail.com wrote:
Checking for null and then doing one thing is a common task. null-con= ditional and null-coalescing operators would be a nice solution.

For= example, given the following pointer:

=C2=A0=C2=A0=C2=A0 unique_ptr= <Connection> connection;

This may happen:

=C2=A0=C2=A0= =C2=A0 if (connection)
=C2=A0=C2=A0=C2=A0 {
=C2=A0=C2=A0=C2=A0 =C2=A0= =C2=A0=C2=A0 connection->sendMessage(msg);
=C2=A0=C2=A0=C2=A0 }
A nice alternative would be:

=C2=A0=C2=A0=C2=A0 connection ?: conn= ection->SendMessage(msg);

Or you could ha= ve just written:

<= div class=3D"subprettyprint">if(conne= ction) connection-><= span style=3D"color: #606;" class=3D"styled-by-prettify">SendMessage= (msg);

T= hat requires only one or two extra keystrokes. Both of these are restricted= to single lines to be executed.

I've had situations where if anything = resolves to false on the left, this ?: would be useful.

Or even bett= er, to carry the concept forward:

=C2=A0=C2=A0=C2=A0 connection?->= ;SendMessage(msg);

Ultimately, I don't t= hink good coding practices make this as necessary=20 as you let on. Most of the time, if you have a pointer, you know it's= =20 valid. It was checked for validity when you received it, and you don't= =20 want to constantly check to see if the thing that was valid before=20 remains valid now.

We don't need to use up precious syntax for a= relatively infrequent case.

Likewise:

=C2=A0=C2=A0=C2=A0 bool succe= ss =3D connection ?: false;

Also easily done= like this:

auto success = =3D bool{connection};
`explicit operator bool` will be called here, since you explicitly asked f= or it.

--

---
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-proposa= ls+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_6522_697935313.1442942158518-- ------=_Part_6521_1704363543.1442942158518-- .