220 9430 article Path: news.gmane.org!not-for-mail From: "Billy O'Neal" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Allowing overloadable operators to be implemented as non-member functions Date: Mon, 24 Feb 2014 13:45:30 -0800 Lines: 282 Approved: news@gmane.org Message-ID: References: <72c8d66b-9053-455d-8af4-96191d84b0cd@isocpp.org> <69a7690f-632f-4ac3-ad76-b56ac59d51f1@isocpp.org> <24fcdc41-d0e1-4641-acb8-e9533ff3ac88@isocpp.org> <7088ca90-6da2-402c-966c-9f7838e5d05c@isocpp.org> <0e40f63d-9a5a-4f55-84a4-abb658da7537@isocpp.org> <514fcafa-cc2c-4887-9bcf-e44b43aadace@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=f46d0444711d5755f004f32de666 X-Trace: ger.gmane.org 1393278362 22606 80.91.229.3 (24 Feb 2014 21:46:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 24 Feb 2014 21:46:02 +0000 (UTC) Cc: myriachan@gmail.com To: std-proposals Original-X-From: std-proposals+bncBDKLBLVE6ADBBIX3V2MAKGQEBDBI6XI@isocpp.org Mon Feb 24 22:46:12 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WI3Lo-0000Bx-E7 for gclcip-std-proposals@m.gmane.org; Mon, 24 Feb 2014 22:46:12 +0100 Original-Received: by mail-ie0-f199.google.com with SMTP id lx4sf29041iec.10 for ; Mon, 24 Feb 2014 13:46:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=bYGVxIb76Pu73JrekFBZHQz7kjueJARM2Uta9opC2DQ=; b=MtNaZL7Ybo97zYGiofcZoIHGKiSCt81f0utAlmg7Wv4CFuNCXOnhyi1Y8GJ1bslJ4w ISVX8MCqgR3Lg+KSzjKO9TS/zJbc28Wt7SNrHG0qiMTSAVlo5ZCLA5EKDlnkTeqm8tV7 xl0ndz2RQXU9QpsRXGh61WMJlhvmQvDG3znWkR47XN0LU6TB4ynZwa8NBYeJevkawYLc mpMJ2O0G0cDyYbHMKBWhCwkAoSyxyPRwipT+RTr7pYE9qdgwF2TpaGjLLkr7yqrwemB6 YTIdNU1U+d80CfzHFUUYwd4vH89VGa81mUzatrPNGWlh/zq8OejePu+mE5Ozv53o4sj3 42hg== X-Gm-Message-State: ALoCoQlJYrP3+NYhxLjZyxGf5MkjK3yDqmNcHGhYcggT4rA/NR1V8s20cIFDGtYQ3cyXWy9hLOXk X-Received: by 10.182.28.36 with SMTP id y4mr9715745obg.46.1393278371331; Mon, 24 Feb 2014 13:46:11 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.182.181.6 with SMTP id ds6ls897503obc.77.gmail; Mon, 24 Feb 2014 13:46:10 -0800 (PST) X-Received: by 10.60.123.10 with SMTP id lw10mr23859080oeb.24.1393278370620; Mon, 24 Feb 2014 13:46:10 -0800 (PST) Original-Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [2607:f8b0:4003:c02::22c]) by mx.google.com with ESMTPS id dq4si15399015oeb.125.2014.02.24.13.46.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Feb 2014 13:46:10 -0800 (PST) Received-SPF: pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::22c as permitted sender) client-ip=2607:f8b0:4003:c02::22c; Original-Received: by mail-oa0-f44.google.com with SMTP id m1so1943864oag.3 for ; Mon, 24 Feb 2014 13:46:10 -0800 (PST) X-Received: by 10.182.233.45 with SMTP id tt13mr19877841obc.9.1393278370375; Mon, 24 Feb 2014 13:46:10 -0800 (PST) Original-Received: by 10.182.87.37 with HTTP; Mon, 24 Feb 2014 13:45:30 -0800 (PST) In-Reply-To: <514fcafa-cc2c-4887-9bcf-e44b43aadace@isocpp.org> X-Original-Sender: billy.oneal@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of billy.oneal@gmail.com designates 2607:f8b0:4003:c02::22c as permitted sender) smtp.mail=billy.oneal@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:9430 Archived-At: --f46d0444711d5755f004f32de666 Content-Type: text/plain; charset=UTF-8 Even that isn't quite the way the built in operator?: works. Most notably, it would allow the user to completely change the conversion / value category that the normal operator?: uses. The rules under 5.16 [expr.cond] have lots of edge cases; even places that result in the program being ill formed as a result of type deduction against the second and third arguments. Would you expect everyone overloading this operator to read / understand this entire type deduction process in order to determine ParentOfLeftAndRight above? Finally, I note that the above program has a bug even if this were allowed, because the result of LeftExpr or RightExpr have the temporaries to which the references are bound only live to the end of the enclosing expression; and optionally have their lifetime extended by being assigned to a reference. Users expect the enclosing expression to be the one containing the use of operator?:, not the expression inside the operator?: operator overload. That makes code like the following undefined behavior, even though it is perfectly well defined for the builtin ?: : #include #include #include std::string Left() { return "left temporary"; } std::string Right() { return "right temporary"; } // Assuming string const& operator?(string const&, string const&) int main() { std::string const& val = (rand() % 2 ? Left() : Right()); std::cout << val << std::endl; } Billy O'Neal https://github.com/BillyONeal/ http://stackoverflow.com/users/82320/billy-oneal On Mon, Feb 24, 2014 at 12:53 PM, Adam Nevraumont wrote: > > > On Saturday, February 22, 2014 12:21:28 AM UTC-5, myri...@gmail.com wrote: >> >> It'd be hacky as all hell, but there is a way that overloading ?: could >> work without losing short-circuiting or breaking the language *too*much. I don't really know why you'd want to overload ?: in the first >> place, but this could work: >> >> const ParentOfLeftAndRight &operator ?:( >> const Conditional &conditional, >> std::function getLeft, >> std::function() getRight) >> { >> return conditional.Evaluate() ? getLeft() : getRight(); >> } >> >> In other words, have the compiler generate lambdas for the expressions on >> the left and right sides of the colon, and try to find an operator ?: >> function that has an overload that will take that argument trio. >> > Rather, > template > std::common_type_t< std::result_of_t, > std::result_of_t > operator?:( > Conditional const& condition, > LeftExpr&& lhs, > RightExpr && rhs > ) > { > if (condition) > return std::forward(lhs)(); > else > return std::forward(rhs)(); > } > where > cond?lhs:rhs; > is transformed into > operator?:( cond, [&]{return lhs;}, [&]{return rhs;} ) > with maybe some verbage to make sure perfect forwarding occurs. > > You could naturally do the same with && and ||. Some way (maybe something > as hacky as the int argument to ++) to distinguish between the > short-circuit and "traditional" overloads of && and ||. > > Short-circuit overloads could be preferred, or it could be ambiguous if > both exist and are otherwise equally good. > > Adding a non-short-circuit ?: seems like a bad idea, for the same reason > why nobody wants to override && and ||. But if we first added > short-circuit && and ||, we can add short-circuit ?: and skip the > non-short-circuit version... > > > > > -- > > --- > 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/. > -- --- 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/. --f46d0444711d5755f004f32de666 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Even that isn't quite the way the built in operator?: = works. Most notably, it would allow the user to completely change the conve= rsion / value category that the normal operator?: uses. The rules under 5.1= 6 [expr.cond] have lots of edge cases; even places that result in the progr= am being ill formed as a result of type deduction against the second and th= ird arguments.

Would you expect everyone overloading this operator to read = / understand this entire type deduction process in order to determine=C2=A0= ParentOfLeftAnd= Right=C2= =A0above?

Fin= ally, I note that the above program has a bug even if this were allowed, be= cause the result of LeftExpr or RightExpr have the temporaries to which the= references are bound only live to the end of the enclosing expression; and= optionally have their lifetime extended by being assigned to a reference. = Users expect the enclosing expression to be the one containing the use of o= perator?:, not the expression inside the operator?: operator overload. That= makes code like the following undefined behavior, even though it is perfec= tly well defined for the builtin ?: :

#include <iostream>=
#include <string><= /font>
#include <cstdlib>
=

std::string Left()
{
return "left temporary";
}

std::string Right()
= {
return "r= ight temporary";
}

// As= suming string const& operator?(string const&, string const&)

int main() {
std::string const&= amp; val =3D (rand() % 2 ? Left() : Right());
std::cout << val << std::endl;
<= font face=3D"arial, sans-serif">}




On Mon, Feb 24, 2014 at 12:53 PM, Adam N= evraumont <afn@theorem.ca> wrote:


On Saturday, February 22, 2014 12:21:28 AM UTC-5, = myri...@gmail.com wrote:
It'd be hacky as all hell, but there is a way that ove= rloading ?: could work without losing short-circuiting or breaking the lang= uage too much.=C2=A0 I don't really know why you'd want to o= verload ?: in the first place, but this could work:

const ParentOfLeftAndRight &operator ?:(
=C2=A0=C2=A0=C2=A0 cons= t Conditional &conditional,
=C2=A0=C2=A0=C2=A0 std::function<cons= t Left &()> getLeft,
=C2=A0=C2=A0=C2=A0 std::function<const Ri= ght &>() getRight)
{
=C2=A0 return conditional.Evaluate() ? ge= tLeft() : getRight();
}

In other words, have the compiler generate lambdas for the express= ions on the left and right sides of the colon, and try to find an operator = ?: function that has an overload that will take that argument trio.
=C2=A0Rather,
template<typename LeftExpr, typ= ename RightExpr>
std::common_type_t< std::result_of_t<LeftExpr(= )>, std::result_of_t<RightExpr()> > operator?:(
=C2=A0=C2=A0= Conditional const& condition,
=C2=A0=C2=A0 LeftExpr&& lhs,
=C2=A0=C2=A0 RightExpr && r= hs
)
{
=C2=A0 if (condition)
=C2=A0=C2=A0=C2=A0 return std::for= ward<LeftExpr>(lhs)();
=C2=A0 else
=C2=A0=C2=A0=C2=A0 return st= d::forward<RightExpr>(rhs)();
}
where
cond?lhs:rhs;
is transformed into
operator?:( cond, [&]{return lhs;}, [&]{retu= rn rhs;} )
with maybe some verbage to make sure perfect forwarding occur= s.

You could naturally do the same with && and ||.=C2=A0 Som= e way (maybe something as hacky as the int argument to ++) to distinguish b= etween the short-circuit and "traditional" overloads of &&= ; and ||.

Short-circuit overloads could be preferred, or it could be ambiguous if= both exist and are otherwise equally good.

Adding a non-short-circu= it ?: seems like a bad idea, for the same reason why nobody wants to overri= de && and ||.=C2=A0 But if we first added short-circuit && = and ||, we can add short-circuit ?: and skip the non-short-circuit version.= ...


=C2=A0=C2=A0
<= font color=3D"#888888">

--
=C2=A0
---
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/gro= up/std-proposals/.

--
 
---
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>.
--f46d0444711d5755f004f32de666-- .