220 37291 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicolas Lesser Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Pointer overload for || Date: Sun, 11 Mar 2018 10:16:56 +0100 Lines: 289 Approved: news@gmane.org Message-ID: References: <1fea07df-46a6-4df2-865a-849be8f8d129@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="f4f5e808dde8ad2a8c05671f7c7a" X-Trace: blaine.gmane.org 1520759696 19769 195.159.176.226 (11 Mar 2018 09:14:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Mar 2018 09:14:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDXKNLEUTADRBCPISPKQKGQE2HPQOKY@isocpp.org Sun Mar 11 10:14:52 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ot0-f200.google.com ([74.125.82.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eux47-00050y-VI for gclcip-std-proposals@m.gmane.org; Sun, 11 Mar 2018 10:14:52 +0100 Original-Received: by mail-ot0-f200.google.com with SMTP id v63sf7580048ota.12 for ; Sun, 11 Mar 2018 01:16:59 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1520759818; cv=pass; d=google.com; s=arc-20160816; b=bb+NGaqlIWTVXT3hgWJ2S2Ae2EoKsQmYOb5iruOI1dvaxCMUAMQDeHLwmWGmlb9KQB NsDUQkWZJmhNCt2Ax453IeADnJR/VzxRfop06D6b2DYHF8jp8BJuE8Z0yDrichKkfRdX iTin44W+k92e9hPopcmZTjjv/YPEKrZbnwFMEwD0R0od7Tt9BU7Ev5X1X4/mwfLTCWNA MjUmNGNkDQLbpS6AimG2KdzCOH5pIifbbt+GlgUAJ+/fdedQSyeorfqYSlFp07hxQG1a EnmSvqapL75CvFi8yQ72Cs0/JZe7DGhd3aQZVFqukGhGvs7MkiZ999dKT6Y2h4VoSoZR a4zg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=pIGs40UYws81yiuwPz/mPdgUMVuvy5R8vyV68+gwLTU=; b=PHjvdYfLluFPK0cGWOugy0asE4CdMBuwydbruwX6RosVFMAXA0TqI/32pejui6QqUN jmNDNmjaK9gcqXw60t95dRwLg2q3EiBXvaev4c+t/uH+hM87Hc02EbtXPFNQQ0df4i5e YfQNn2B7KJAwPXkS0HcSVf1D8wFW7Gq3PkkQpSSIEIP82p6KFDeVRBlfNBc7221u00Qw X94m6fEVGEo6u12FDcjPpdwL/+7d9MErgbD5SnkSxLE0SdKqVqkpjtgQVFuFx+xC50Xl fjUGsw3/CqR+9ALM3N/rbac8fTe2yjezGdzMzh5kPJe1G1YDdkhG4f+1JJ3nfiaMlyf6 QOBQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OM9VWbHE; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject: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; bh=pIGs40UYws81yiuwPz/mPdgUMVuvy5R8vyV68+gwLTU=; b=xtz8gzmwNI8QrGRSymi9EsEf2HAYOf5b9CvBqLE6xZyOH9GluTc+7hxWMfwWRkedEq 0PF+/wJFRf0GuLmFAgbA1JR88aZZ2upaSkKxLO8Yu5KenDKqoN3Ystzi2WTrnTfU/iJM JhHo0S2Ckitfcb39MUS2uf90c6zAKGZ2iG4SxT5zj6MEyCfgU2iecZIrLeuK4OTbo702 UA1Y5nFTLWEaFSxuXTfaq+CItTJL7Yd8WrB7nW4MusFDz9KqyJz0/oiMbggILyyYLhWw xxMHSuMyVCO4MilQCngyyWbKI/EEq/HGFCgGs1RKb88OoYEHZC2SbwePA001w9lR774p gU8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=pIGs40UYws81yiuwPz/mPdgUMVuvy5R8vyV68+gwLTU=; b=uZK4LatT3lUGiIGusDdCSZkgh8WnnbaejfyLTol9aTHRZhNBvtZ52FbGD208HeZ+on w7+XJluCAMR8I0CTZWubooQsNFpvqE3EVmJQ6kpw4X2TJ+glzyxKEQ+sfiE90WJl79e/ iriD6vx+HNjYUglEGrMa0O+mYUu8NuO3D1OrtbmQJ+O83DOcOR+ErfbkJG5cC+Vpdjy/ kGiKv9jiiQzik+NbCPs70qQlRzLI/S1ggqExD/n24EeNWP2zm+e2Z2kI5tD1MeiyBYeF z31f2XTc3fU3MB9BW1n4obANqJ1cN/rB3o9Kvd/1JtFo8h0PhaEkFZ1QS7hC7JjoWTw1 T58A== X-Gm-Message-State: AElRT7GYyRwBLy59igleV/pWNzXiVwosm2l0xJBvAlJpBR4lW1b421Dn WazXMXwhLmakxx2aL1t5Rj00ow== X-Google-Smtp-Source: AG47ELvhZ5qw8xu/zZQjqU3JmFoMdtFzZ7G5nJ/wVru01/wOOIgE8KPm25m6CUnXRgoO3rCx16GaBw== X-Received: by 10.157.81.204 with SMTP id d12mr2166382oth.59.1520759818604; Sun, 11 Mar 2018 01:16:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.202.235.143 with SMTP id j137ls49688oih.12.gmail; Sun, 11 Mar 2018 01:16:57 -0800 (PST) X-Received: by 10.202.186.6 with SMTP id k6mr2692864oif.169.1520759817469; Sun, 11 Mar 2018 01:16:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520759817; cv=none; d=google.com; s=arc-20160816; b=GUlg+gC7bRT+ievrCoRrM0Ug7ZW/UNeERiN72gKP4Ekk2fODUZJ/NXkmpvB2WxaQDp KJz4Uch7ONPdb9HV8rTn0Tdgiuu1HWp+OATU4rmwy08CmtPwkfBCesERKbMwu+lpK4Hq f79hUxxsaAC/BRkQ/rSM575Wve0om25VJGOux/DZL/OAWSglKpWb+4/VfuvuLQykxPP9 mNGI0uKE9PEzN8Ss4nqjsHPQlWoh3TChu9vxReZdXENVNceCHmOtVjXAGjkdu+a9Avlk 49JucHPQdHf//hQOd5IFeQWkjml6y9nGkHWt0INyFBq5YRMbNzmPb2kU/e8xHdE3QuMC 1o7Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=7ra8dWjDVwH9MrO+IdpzMnE5/7FUmRXVuTcZR37DMQg=; b=mLlx8XvesGfDbfjSu8jH4zuiZJwiVwyuf8RB9r7JIz0GgHCiNEQvw3/SW7W8A+Haau OwFbu4+n2a2ANgdvUdEqBRLXOg+hHhYoNL0Iis6pXmUwfs7+J1ONPbuEgWTXknXjlCGB VOJedwTWrjxbayzLnJE6uubNC7NGUrYppPYS9CVgW+Bxk4xsHGSd/dw5LLNhR0bJ4RWE i26cDZMOhWwj5rPQetuuntBOJxDE2FEvyvVBEe9enUdveEfyPZfgFsOueDPoJR1ksGNw uS7AsVkGQCuRe04X8lw8xyS1RYjkJGu1CUbdyBLpqWu0//v4/ipKg4g6Mpb9/pMQln2n aKzg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OM9VWbHE; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id l13sor1948420oib.67.2018.03.11.01.16.57 for (Google Transport Security); Sun, 11 Mar 2018 01:16:57 -0800 (PST) Received-SPF: pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.202.13.8 with SMTP id 8mr2646395oin.272.1520759816922; Sun, 11 Mar 2018 01:16:56 -0800 (PST) Original-Received: by 2002:a9d:5e01:0:0:0:0:0 with HTTP; Sun, 11 Mar 2018 01:16:56 -0800 (PST) Original-Received: by 2002:a9d:5e01:0:0:0:0:0 with HTTP; Sun, 11 Mar 2018 01:16:56 -0800 (PST) In-Reply-To: X-Original-Sender: blitzrakete@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=OM9VWbHE; spf=pass (google.com: domain of blitzrakete@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=blitzrakete@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:37291 Archived-At: --f4f5e808dde8ad2a8c05671f7c7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I don't see the point. How is your if not succinct? if (!ptr) ptr =3D new int; is very short and understandable. More so than your idea, as that complicates the logical or operator. Also that inverted logic has a high chance of confusing anyone who comes across it, and it some cases, it is not even clear which or operator you choose. var =3D var || allocate(); If allocate doesn't return a pointer, but a boolean (or due to a refactor it changes) then the expression above would no longer do the right thing: assign 1 to var if either expression is true, which is not expected. You could take inspiration from Python or use the GNU binary op Ga=C5=A1per mentioned: x =3D new int if (!x); But I don't like that either. In short, the first if version is by far the most understandable and clear way of achieving what you want IMO. On Mar 11, 2018 10:03 AM, "Ga=C5=A1per A=C5=BEman" = wrote: > In my morning fog I forgot I needed to specify that it was the version of > assert where you only evaluate the message portion if the condition faile= d. > Not the standard assert. > > On Sun, Mar 11, 2018 at 8:58 AM, Ga=C5=A1per A=C5=BEman > wrote: > >> There is a binary form of the conditional operator that is a gnu >> extension: >> >> void foo(int *x) { >> x =3D x?:new int; >> } >> >> It's defined as >> >> CEXPR ?: FEXPR; >> >> and rewritten into >> >> { >> auto&& x =3D CEXPR; >> if (x) { return x; } else { return FEXPR; } >> } >> >> Perhaps you could propose that instead, as it's far more general. It's a >> GNU extension because certain macros (assert comes to mind) are much eas= ier >> to implement if you have it. >> >> G >> >> >> >> >> On Sun, Mar 11, 2018, 08:38 wrote: >> >>> Not sure how this will be received -- I haven't posted here much. Just >>> thought it would be worth mentioning this idea. >>> >>> Suppose you have an API that you want to optionally allocate storage fo= r >>> your user. They can either pass in a pointer to some existing allocate= d >>> space, or pass in a null pointer and space is allocated for them. >>> >>> void foo(int *x) { >>> if (x =3D=3D nullptr) { >>> x =3D new int; >>> } >>> // etc. >>> } >>> >>> Just figured it would be a decent idea if the || operator received a >>> pointer overload. Then you could write the more succinct >>> >>> void foo(int *x) { >>> x =3D x || new int; >>> } >>> >>> or even (ducks for cover) >>> >>> void foo(int *x) { >>> x ||=3D new int; >>> } >>> >>> would be nice. >>> >>> Currently, if I am not mistaken, || (excluding user-defined overloads) >>> is a boolean-only operator. It is indeed the case that nullptr is the = only >>> value that becomes false when cast to a boolean, and all other pointer >>> values become true. So I don't see how adding an || overload for point= ers >>> would break any existing code. >>> >>> The main thing that would make this a no-go would be if the semantics o= f >>> || required that both operands be evaluated -- whether or not the left-= hand >>> one is false. Then the whole point as I see it would be lost - the abo= ve >>> examples would merely leak memory. >>> >>> - Jefferson Carpenter >>> >>> -- >>> 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. >>> To view this discussion on the web visit https://groups.google.com/a/is >>> ocpp.org/d/msgid/std-proposals/1fea07df-46a6-4df2-865a-849be >>> 8f8d129%40isocpp.org >>> >>> . >>> >> > -- > 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. > To view this discussion on the web visit https://groups.google.com/a/ > isocpp.org/d/msgid/std-proposals/CAANG%3DkUmThSamFisncxMCaqFd6Ze7GWH- > q%2BTjMn4YfFTn2T8%2Bw%40mail.gmail.com > > . > --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/CALmDwq3powZ_ytSPztv%3DZz-TryE1jcDwDsDhtoABggvcF= eJK%2Bg%40mail.gmail.com. --f4f5e808dde8ad2a8c05671f7c7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I don't see the point. How is your if not succinct?
if (!ptr)
=C2=A0 =C2=A0 ptr =3D new int;

is very short and understandable. More so than your idea, as that= complicates the logical or operator.

Also that inverted logic has a high chance of confusing anyon= e who comes across it, and it some cases, it is not even clear which or ope= rator you choose.

var = =3D var || allocate();

I= f allocate doesn't return a pointer, but a boolean (or due to a refacto= r it changes) then the expression above would no longer do the right thing:= assign 1 to var if either expression is true, which is not expected.
=

You could take inspiration fr= om Python or use the GNU binary op Ga=C5=A1per mentioned:

x =3D new int if (!x);

But I don't like that either. In short= , the first if version is by far the most understandable and clear way of a= chieving what you want IMO.

On Mar 11, 2018 10:03 AM, "Ga=C5=A1per A=C5=BEma= n" <gas= per.azman@gmail.com> wrote:
In my morning fog I forgot I needed to spec= ify that it was the version of assert where you only evaluate the message p= ortion if the condition failed. Not the standard assert.

On Sun, Mar 11, 2018 at 8:58 A= M, Ga=C5=A1per A=C5=BEman <gasper.azman@gmail.com> wrot= e:
There is a binary form of the conditional operator that is a gnu extensio= n:

void foo(int *x) {
=C2=A0 x =3D x?:ne= w int;
}

It's defined as
<= br>
CEXPR ?: FEXPR;

and rewritten into

{
=C2=A0 =C2=A0auto&& x =3D CEXPR= ;
=C2=A0 =C2=A0if (x) { return x; } else { return FEXPR; }
<= div>}

Perhaps you could propose that instead, as i= t's far more general. It's a GNU extension because certain macros (= assert comes to mind) are much easier to implement if you have it.

<= /div>
G
=




On Sun, Mar 11, 2018, 08:38 <jeffersoncar= penter2@gmail.com> wrote:
Not sure how this will be received -- I haven't pos= ted here much.=C2=A0 Just thought it would be worth mentioning this idea.
Suppose you have an API that you want to optionally allocate storage = for your user.=C2=A0 They can either pass in a pointer to some existing all= ocated space, or pass in a null pointer and space is allocated for them.
void foo(int *x) {
=C2=A0 if (x =3D=3D nullptr) {
=C2=A0=C2=A0= =C2=A0 x =3D new int;
=C2=A0 }
=C2=A0 // etc.
}

Just figure= d it would be a decent idea if the || operator received a pointer overload.= =C2=A0 Then you could write the more succinct

void foo(int *x) {
= =C2=A0 x =3D x || new int;
}

or even (ducks for cover)

voi= d foo(int *x) {
=C2=A0 x ||=3D new int;
}

would be nice.
Currently, if I am not mistaken, || (excluding user-defined overloads) is= a boolean-only operator.=C2=A0 It is indeed the case that nullptr is the o= nly value that becomes false when cast to a boolean, and all other pointer = values become true.=C2=A0 So I don't see how adding an || overload for = pointers would break any existing code.

The main thing that would ma= ke this a no-go would be if the semantics of || required that both operands= be evaluated -- whether or not the left-hand one is false.=C2=A0 Then the = whole point as I see it would be lost - the above examples would merely lea= k memory.

- Jefferson Carpenter

--
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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-= proposals/1fea07df-46a6-4df2-865a-849be8f8d129%40isocpp.org.<= br>

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgi= d/std-proposals/CAANG%3DkUmThSamFisncxMCaqFd6Ze7GWH-q%2BTjMn= 4YfFTn2T8%2Bw%40mail.gmail.com.

--
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALmDwq3powZ_= ytSPztv%3DZz-TryE1jcDwDsDhtoABggvcFeJK%2Bg%40mail.gmail.com.
--f4f5e808dde8ad2a8c05671f7c7a-- .