220 41139 <9b3ff05d-47d0-44a7-a4c4-0415dbc3b966@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Jason Rice Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Parametric Expressions Operator Overloading Date: Thu, 29 Nov 2018 17:03:46 -0800 (PST) Lines: 103 Approved: news@gmane.org Message-ID: <9b3ff05d-47d0-44a7-a4c4-0415dbc3b966@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3248_1645552774.1543539826236" X-Trace: blaine.gmane.org 1543539708 31777 195.159.176.226 (30 Nov 2018 01:01:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Nov 2018 01:01:48 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCBKPROT3IBBB44YQLQAKGQEK7NBHWY@isocpp.org Fri Nov 30 02:01:44 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f71.google.com ([209.85.161.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gSXBf-000847-4G for gclcip-std-proposals@m.gmane.org; Fri, 30 Nov 2018 02:01:43 +0100 Original-Received: by mail-yw1-f71.google.com with SMTP id j81sf2708998ywj.15 for ; Thu, 29 Nov 2018 17:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=1Hi8ARWt6UjBXac58gMkfL4i6HF2oK84mB6Lfu6xFlU=; b=xRpv5Qc/P6Ks19sqWOecTFhxhDLHo/iew+Mby3WvC+U7SdGBpKolUvj68z7uqz4jjY 0PUfniXU2WhzlQcl6tHIcVkrQ4TxNvQ0Fea0/e72bFqWgFQAIP/xWQU9Ob3nuyesPPpY dDdo8JlFf3D9CY+98GvttDUHd+SagItbpEmHZ/fkzD0EwfV3c0ifI7a9l03En47DeL5d KVVuEVkfOkgEmg18VSKOiwuxO5VQGCIW/kPSxWF2GuOFyfc5WoKsS8LyN/HnGcx0V9kM a7tLumevX3BZv2YKHybJLiYsPlgcTaX1q2OCaKQ4dY0CoKO/cIjl2FZlHAdPsGOdEJR8 t7qA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=1Hi8ARWt6UjBXac58gMkfL4i6HF2oK84mB6Lfu6xFlU=; b=BMU9/P6eCBelEHFVarPM1m1FeTXty1XklkHN56XF4k7X40w4+j+E4BBKjT35bNlYpQ WYHQwA981ZKXfzUaKXIhDovmTE3/HUluBWyuO6j1Uq0NRhBuh6brjrifwyXi4m0iIjMB Eco1seClRnLzluLxHShMJ63G/JT3p6/eECUPpa5PV5WU09RVlXzxgb3INCRm2TeeMcnS Y1lrgVWQvqbWhYl/6ZWpUwlDzfjiingVi0CR92ZgqGjvFGYvQKD08d0Oq7h8rzczt/cI yuuuUefiOORTkrZvdnxBdx0uM36wcJmNluc8Uz1tNN+Rw1vysJFDa2v9S3pMIpP3KErq /3fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :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=1Hi8ARWt6UjBXac58gMkfL4i6HF2oK84mB6Lfu6xFlU=; b=KI3E3RrOsizoWI2vpgyowfyukfCel07irkG8wrVHSzQlI7+mCe/3hT8ZUIyUgCASxy yuvKW6VWADD1eKIMRbi79pWq6u04f6gdlem5vOA1NQZh+Nr+Dfg5+jsRIELoyX4/kEMZ RDyIp5m1O9a9iRdCf1Icwh/8KzTaPRv1zZoikoufQ1xKJmGcKKjOVnzTxEiG6L9zp6D/ BjitvbHeuJ2A2U5Uh2oLsVsRqqyM8wn+kjGw9ydcNGZYG902GB41YGfKTVnlELCRau3/ rzwbdC71RjhHyF8GkFvIjAn0HFR39O2+FdT1B3JLBgcHrh67mEtTNccnq4lUgaHYqj7o /wiA== X-Gm-Message-State: AA+aEWZWFpVt0jEg71BxgjXGltBagDDHmkJqOV4ZthWfBhz1RA6CoSrz Of6klYqlevHaC41lYcBOetrxvw== X-Google-Smtp-Source: AFSGD/WkF1Ms7AtZmWtuMoCDOtSfEGv6XA5T/Iw5M1MQTHGWfrk1C46w9VoO9GBqXmCc/YbWZgqqJQ== X-Received: by 2002:a25:83c3:: with SMTP id v3-v6mr2165976ybm.29.1543539828085; Thu, 29 Nov 2018 17:03:48 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a81:3515:: with SMTP id c21ls1960634ywa.8.gmail; Thu, 29 Nov 2018 17:03:47 -0800 (PST) X-Received: by 2002:a81:9841:: with SMTP id p62mr42108ywg.0.1543539826798; Thu, 29 Nov 2018 17:03:46 -0800 (PST) X-Original-Sender: ricejasonf@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:41139 Archived-At: ------=_Part_3248_1645552774.1543539826236 Content-Type: multipart/alternative; boundary="----=_Part_3249_569669352.1543539826236" ------=_Part_3249_569669352.1543539826236 Content-Type: text/plain; charset="UTF-8" I would like to float an idea for handling operator overloading with Parametric Expressions P1221R0/D1221 which has not been looked at by the committee yet. In that paper I made some vague assertions about how to handle operator overloading so I am considering a couple of options. Note that there is no overloading or ADL with non-operator parametric expressions. I would like to keep it that way, but operator overloading is a bit different. *OPTION #1* In the set of overload candidates, what if a viable parametric expression was always preferred over normal candidates? Since parametric expression recursion is not allowed, it would not be viable within its own definition so it would be allowed to call the operator again where the parametric expression is not considered. Allowing it to server as a wrapper in this way could provide a couple of possibilities for users: - Transform or lift values before calling overloaded operator that might include ADL candidates - Control evaluation of inputs before calling overloaded operator that might include ADL candidates - Bypass ADL entirely (which is useful since operators are typically unqualified) *OPTION #2* Always prefer viable function candidates over parametric expressions - the story ends, you wake up in your bed and believe whatever you want to believe. Your consideration and feedback is greatly appreciated. Thanks, Jason Rice -- 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/9b3ff05d-47d0-44a7-a4c4-0415dbc3b966%40isocpp.org. ------=_Part_3249_569669352.1543539826236 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would like to float an idea for handling operator overlo= ading with Parametric Expressions P1221R0/D1221
which has not been looke= d at by the committee yet. In that paper I made some vague assertions about= how
to handle operator overloading so I am considering a couple of opti= ons.

Note that there is no overloading or ADL with non-operator para= metric expressions. I would like to keep it
that way, but operator overl= oading is a bit different.

OPTION #1

In the set of ove= rload candidates, what if a viable parametric expression was always preferr= ed over normal
candidates? Since parametric expression recursion is not = allowed, it would not be viable within its own=C2=A0
definition so it w= ould be allowed to call the operator again where the parametric expression = is not
considered.

Allowing it to server as a wrapper in this way= could provide a couple of possibilities for users:

  • =C2=A0 T= ransform or lift values before calling overloaded operator that might inclu= de ADL candidates
  • =C2=A0 Control evaluation of inputs before callin= g overloaded operator that might include ADL candidates
  • =C2=A0 Bypa= ss ADL entirely (which is useful since operators are typically unqualified)=

OPTION #2

Always prefer viable function candida= tes over parametric expressions - the story ends, you wake up in your
be= d and believe whatever you want to believe.

Your consideration and f= eedback is greatly appreciated.


Thanks,
Jason Rice

--
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/9b3ff05d-47d0-44a7-a4c4-0415dbc3b966= %40isocpp.org.
------=_Part_3249_569669352.1543539826236-- ------=_Part_3248_1645552774.1543539826236-- .