220 37314 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Hodges Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Pointer overload for || Date: Mon, 12 Mar 2018 11:42:24 +0100 Lines: 430 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="001a1147b7262a52a9056734cce2" X-Trace: blaine.gmane.org 1520851226 11240 195.159.176.226 (12 Mar 2018 10:40:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Mar 2018 10:40:26 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD4PBM7UWAHRBENTTHKQKGQEGW5ARXA@isocpp.org Mon Mar 12 11:40:21 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f200.google.com ([209.85.223.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1evKsO-0002mE-18 for gclcip-std-proposals@m.gmane.org; Mon, 12 Mar 2018 11:40:20 +0100 Original-Received: by mail-io0-f200.google.com with SMTP id 188sf8942496iou.14 for ; Mon, 12 Mar 2018 03:42:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1520851346; cv=pass; d=google.com; s=arc-20160816; b=uEmUSGFtlgKwHxZip0j4UqKan6wsEIeRjXAQrrYALeeGn/G5EtGZgCjyZ37idvTF6M 2S+2cLV2XrmzEJdliSLJ8rdQOjoQtZovDpWX5T5oZw+GTLrc84Z1MpjJBH9r9QeoNkEl jgaHTRr/qy5+vdjS2dtoMgtJZIG85ub6ukH1Ovcp0ZkwsAI0QRyFSvdSfvFXPoPhBOdQ 5Tyo1SOf2CCT5WRkUNCQ8fbYQkdf6QocNwOLDuets+acYhBvZmfFeoYPBHIG9wGUJPGL jOqSs6p8GbUAp42lQLLLb15e3Jx35y+PBbq6obHqs80/KF/yvbK7pG6MAW4094kb05Fr mr+Q== 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=CIGkeIa4US1F9eqErQj4xtmba7ax4N4nc7LAbM5jZlU=; b=bSbqCyWavUuXLYCCiq7z3j8ueZaclFrZY3QqYFkJJGgbUC8fgapYel3xDUSSqcRup8 F+4EHGkHmfJAF6BB/Muor36lmBF6Sm9sjEwg3L41zZlqZEH4PBZRwZd+Jb4GNTGKQ3lu wW4uLdYObysF2OJQB3M/GqxTbtvm1ERMkO8tvEGrWsLDn3lYU5Heff6R2I14g5I7gVd5 2XlqRAkDCgBE2bJn/RdrEx4B7BhCtc3hBvrM+dsFc8UbHmvP/gWvrtFTn/v6l7swVNaQ e7N45wSD722cueKTkIMjy3o86qXJnoD+U5O+YE927lJN73MpGy/pbuOW5ggENPYsTg4B i43A== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DKwbZAgP; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=hodges.r@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=CIGkeIa4US1F9eqErQj4xtmba7ax4N4nc7LAbM5jZlU=; b=qarNrSj/0sqDZ/fVHRcrvYwdqjlZFZLygsChzEdTjfiJkUf5s90PLTVvpO4Pt8qX8g 3LrCnCJb8bqewOCwVqhRd9hlwf05s6LKqq6bV/l5AompAU3dXGD2uwhqh83COxP9uhCi EH13cWggd0xHtB6ds0mQiRQJ5PrQcm341hY/QVQC3DlCDmBQGHesd4z0+PCs1BO3IWS2 jQCb4DmgXZDpSVuSMtw45WxrvnGHE5R6yboS3Rw6o4Px5EaP3UvpUyiz/947y3l+gPKi KwV2b44zdeN0UAvaKlzUHjbufyYv+cTh2AVCVYjeATPxlegijTkyOO+m30iT9gG4Wc8b gtNQ== 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=CIGkeIa4US1F9eqErQj4xtmba7ax4N4nc7LAbM5jZlU=; b=onmAMeekvkPQ7YdPm/XtxT3Bt30WaPTW1FsONT4XOO0YzjBmhYfQVD1trK/i+Kt4EG WUVL4N+NsnsH+PZpbULLv0CHopuDUK+zp0dQKTmhx+xYC4YMyLlU8QQMva0lw5xBgyr1 6m82J4s3fKiKg1VDBIBBXq63opzylb1AZ5moEz5dQzmoG4Q0Upvn9QuZPovZLrFK31eO SM/Jerev8xx/hNn4CwWDRClsysPxpQ9Aj+buw5CW/oPCFyeDZB8z2eZnLAnJLc+bvkhm f5iirWCDry+QOWhI5hhehZdw6OtSyu0N3d6dsBjiupq2Gc1Qc7mPYN+2EzQnRKDpDcaC mG/A== X-Gm-Message-State: AElRT7GXFZ8GzqWVV4uc+TY+JUZsNMPCGzqrPMOgs9pwOuCSsfeLB1yF 70eqEH4crMTWyGGiSwfRhyRYIw== X-Google-Smtp-Source: AG47ELuxmv4lEdeGQQ02HF2yUdQWmDNHSw2XSFZXb3IE1cP3x5sZ+2Ru2GtuJXFyhrzlr7123nhDdg== X-Received: by 10.36.86.4 with SMTP id o4mr3967797itb.55.1520851346877; Mon, 12 Mar 2018 03:42:26 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.81.11 with SMTP id f11ls664001iob.13.gmail; Mon, 12 Mar 2018 03:42:25 -0700 (PDT) X-Received: by 10.107.63.68 with SMTP id m65mr8795959ioa.195.1520851345321; Mon, 12 Mar 2018 03:42:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520851345; cv=none; d=google.com; s=arc-20160816; b=LIW7l8nPh7LMe758ujBYIP8sLzDoXVZgQYXXiOznwGutht3wKzG5jnBj/ZnCMMwI3I 3p91WQbi6f0NkKHj36fNVW6BS7e4kghR9jIWBmHILb7MFNKzux1b12oXw4hUeRZ35Q2V +D+WxG+n+079HhCUP0d+DXfj9Fp2a6cvoQL9vRcBQfLSMsSiP4pPhLiiUsBbuYJopSlP sWxPEQ5XcOqjADzFJg6uYmh6J/XwPDqAzYI9ULLbv9Tjopgx81OK0mJlce6Zy+DKa7Nm 19uNjXOhkqF8mu1uYHz+GZf82iSDdNTTD/kyktnVLr9E8tbBd7R3nrr2fnc/Buon41U2 KgGA== 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=9D+wrzqOggCyAF4bgLuvO/gXdUN0Q6nFz84WR/ek3Dw=; b=IdEihXKYMGcOS+T+VNMJYpZBh2UA1xx7THiakCRD79QjJD55niYGirrXo1nLWxdYo1 +2IiEZm0Wp3jSlPEnfLSxbOweFsvI8rzCD0NeR5ZCjmixlIWUNliHTmMpPfect81AAnl Kn55tB3QzXREEwMNry+jdYczrFINyMGynz4kJlZOR78/KySTwjD3tMbMsajhExnPBsAN jh6rISMVtfgd8cOvzsJu3XnHO1yqda2uObD4fCiHjaK+pQlW+ONV4XXvSF/5dCRTrbG6 eGzl2qpROZM3S+KLPRghPkICqV7EV6fT03cJZg/k4OyRNrRE5VZdvPQkZ2CHe4hOnX/4 VSfw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DKwbZAgP; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=hodges.r@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id 129sor2338194ity.85.2018.03.12.03.42.25 for (Google Transport Security); Mon, 12 Mar 2018 03:42:25 -0700 (PDT) Received-SPF: pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 10.36.127.10 with SMTP id r10mr8115243itc.101.1520851344837; Mon, 12 Mar 2018 03:42:24 -0700 (PDT) Original-Received: by 10.2.102.105 with HTTP; Mon, 12 Mar 2018 03:42:24 -0700 (PDT) In-Reply-To: X-Original-Sender: hodges.r@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=DKwbZAgP; spf=pass (google.com: domain of hodges.r@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=hodges.r@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:37314 Archived-At: --001a1147b7262a52a9056734cce2 Content-Type: text/plain; charset="UTF-8" On 12 March 2018 at 08:33, Richard Hodges wrote: > I am a little surprised and dismayed at the eagerness to resort to macros. > > We can already safely overload operators with a custom generator type. No > need for macros, language extensions or any other magic. > > live demonstration: http://coliru.stacked-crooked.com/a/bc751df610a220ce > > > > However, please don't take my posting "how-to" code as an endorsement. Having written this, I then implemented a similar concept for unique_ptr (a little more tricky because of the redundant r-value assignment). This led me to then look at the "|=" case, but I don't think that makes semantic sense when applied to pointers: Consider: p |= new_thing(); In the above code, do we mean that we wish to replace p with a new thing if empty, or does it mean that we wish to merge a new thing into the object referenced by p? I am inclined to argue that to me it means the latter. > > > On 12 March 2018 at 01:28, wrote: > >> >> >> On Sunday, March 11, 2018 at 7:06:59 PM UTC+1, Miguel Ojeda wrote: >> >>> On Sun, Mar 11, 2018 at 9:38 AM, 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 >>> for >>> > your user. They can either pass in a pointer to some existing >>> allocated >>> > space, or pass in a null pointer and space is allocated for them. >>> > >>> > void foo(int *x) { >>> > if (x == nullptr) { >>> > x = 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 = x || new int; >>> > } >>> > >>> > or even (ducks for cover) >>> > >>> > void foo(int *x) { >>> > x ||= new int; >>> > } >>> >>> Your first version is the best one, to be honest :-) In any case, if >>> you really need something like you propose (a pseudo-DSL, generated >>> code, ...?), then a macro with a descriptive name would be the >>> simplest and most readable, e.g. for your second version: >>> >>> #define OR_ELSE(v, e) ((v) ? (v) : (e)) >>> >>> // ... >>> x = OR_ELSE(x, new int); >>> >>> For your third version: >>> >>> #define ENSURE_INIT(v, e) do { if (not (v)) (v) = (e); } >>> while(false) >>> >>> // ... >>> ENSURE_INIT(x, new int); >>> >>> >> This solution is not perfect because it reuse `v` multiple times, if >> value is not simply value it could be problematic. >> >> Better would be using lambda similar like in your next point: >> >> >> #define OR_ELSE(v, e) ([&](auto MACRO_OR_ELSE_VALUE_X){ return (MACRO_OR_ELSE_VALUE_X >> ? MACRO_OR_ELSE_VALUE_X : (e)); }(v)) >> >> >> >> This will allow evaluate `v` only once and can be inserted in other >> expressions: >> >> auto z = h() ? OR_ELSE(OR_ELSE(x, foo()), bar()) : zz(); >> >> >> >> >>> If you are really keen on having the operator, you could always >>> approximate like: >>> >>> #define LAZY(x) [](){ return (x); } >>> >>> template >>> T operator||(T p, E e) >>> { >>> if (p) >>> return p; >>> return e(); >>> } >>> >>> // ... >>> x = x || LAZY(new int); >>> >>> Similar for |=; and add something to restrict the overloads as needed. >>> >>> Now, if you want to make a cool proposal: >>> >>> template >>> T operator||(T p, E e) >>> { >>> if (p) >>> return p; >>> return e; >>> } >>> >>> // ... >>> x = x || new int; >>> >>> ;-) >>> >>> Cheers, >>> Miguel >>> >> -- >> 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/c7cd5d95-0031-4e50-b7a1- >> 9adcff695bd2%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/CALvx3hbrrb6tJJYEG7S9q1YrRWSXXi%2BOCW9n1siXRfFjjxTDYA%40mail.gmail.com. --001a1147b7262a52a9056734cce2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On 12 March 2018 at 08:33, Richard Hodges <hodges.r@gmail.com>= wrote:
I am a li= ttle surprised and dismayed at the eagerness to resort to macros.

<= /div>
We can already safely overload operators with a custom generator = type. No need for macros, language extensions or any other magic.



<= /div>


However, please = don't take my posting "how-to" code as an endorsement.
<= div>
Having written this, I then implemented a similar concep= t for unique_ptr (a little more tricky because of the redundant r-value ass= ignment).

This led me to then look at the "|= =3D" case, but I don't think that makes semantic sense when applie= d to pointers:

Consider:

= p |=3D new_thing();=C2=A0 =C2=A0

In the above code, do we mean that we wish to= replace p with a new thing if empty, or does it mean that we wish to merge= a new thing into the object referenced by p?


=
I am inclined to argue that to me it means the latter.



=C2=A0


On 12 March 2018 at 01:28, <inkwizytoryankes@gmail.= com> wrote:


On Sunday, March 11, 2018 at 7:06:59 PM UTC+1, Miguel Ojeda wrote= :
On Sun, Mar 11, 2018 at 9:38 AM, =C2=A0<j= efferson...@gmail.com> wrote:
> Not sure how this will be received -- I haven't posted here mu= ch.=C2=A0 Just
> thought it would be worth mentioning this idea.
>
> Suppose you have an API that you want to optionally allocate stora= ge for
> your user.=C2=A0 They can either pass in a pointer to some existin= g allocated
> 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 x =3D new int;
> =C2=A0 }
> =C2=A0 // etc.
> }
>
> Just figured 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)
>
> void foo(int *x) {
> =C2=A0 x ||=3D new int;
> }

Your first version is the best one, to be honest :-) In any case, if
you really need something like you propose (a pseudo-DSL, generated
code, ...?), then a macro with a descriptive name would be the
simplest and most readable, e.g. for your second version:

=C2=A0 =C2=A0 #define OR_ELSE(v, e) ((v) ? (v) : (e))

=C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 x =3D OR_ELSE(x, new int);

For your third version:

=C2=A0 =C2=A0 #define ENSURE_INIT(v, e) do { if (not (v)) (v) =3D (e); = } while(false)

=C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 ENSURE_INIT(x, new int);


This solution is not perfect because = it reuse `v` multiple times, if value is not simply value it could be probl= ematic.

Better would be using lambda similar like in your next point= :


#define OR_ELSE(v, e)<= /span> ([&](auto MACRO_OR_ELS= E_VALUE_X){ <= /span>return = (MACRO_OR_ELSE_VALUE= _X ? MACRO_O= R_ELSE_VALUE_X : (e= )); }(v))


This will allow evaluate `v` only once and can be inserted in other ex= pressions:

auto z =3D h() ? OR_ELSE(OR= _ELSE(x, foo()), bar()) : zz();


=C2=A0
If you are really keen on having the operator, you could alwa= ys
approximate like:

=C2=A0 =C2=A0 #define LAZY(x) [](){ return (x); }

=C2=A0 =C2=A0 template <typename T, typename E>
=C2=A0 =C2=A0 T operator||(T p, E e)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0if (p)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return p;
=C2=A0 =C2=A0 =C2=A0 =C2=A0return e();
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 x =3D x || LAZY(new int);

Similar for |=3D; and add something to restrict the overloads as needed= ..

Now, if you want to make a cool proposal:

=C2=A0 =C2=A0 template <typename T, expression E>
=C2=A0 =C2=A0 T operator||(T p, E e)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0if (p)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return p;
=C2=A0 =C2=A0 =C2=A0 =C2=A0return e;
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 x =3D x || new int;

;-)

Cheers,
Miguel

--
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/c7cd= 5d95-0031-4e50-b7a1-9adcff695bd2%40isocpp.org.


--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CALvx3hbrrb6tJJ= YEG7S9q1YrRWSXXi%2BOCW9n1siXRfFjjxTDYA%40mail.gmail.com.
--001a1147b7262a52a9056734cce2-- .