220 13945 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Default values for n4191 fold expressions Date: Wed, 15 Oct 2014 19:22:45 -0700 Lines: 179 Approved: news@gmane.org Message-ID: References: <997390c5-072b-407a-bce9-22a29fc5e228@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b86d52083e784050580ecfc X-Trace: ger.gmane.org 1413426175 31036 80.91.229.3 (16 Oct 2014 02:22:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 16 Oct 2014 02:22:55 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBB5WX7SQQKGQE2TBTUVI@isocpp.org Thu Oct 16 04:22:49 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pd0-f200.google.com ([209.85.192.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XeaiF-00047K-Ud for gclcip-std-proposals@m.gmane.org; Thu, 16 Oct 2014 04:22:48 +0200 Original-Received: by mail-pd0-f200.google.com with SMTP id ft15sf12660170pdb.11 for ; Wed, 15 Oct 2014 19:22:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from: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:content-type; bh=y2mR26G1MVSlDHHk8MBNqRHygstU5QRRrFktxF4f06o=; b=UoLOWhINsIKQzokNdTQBaSVg6Px6KZNqkIIuIWoyPlUqE/mIEZstaPZCxNfnzrHn6n h3PBS92lit26uRMCj38Btv25HgLWqoGe10U0+Gfe0KTGDygd3pAMgt2IWkZugwR/ltEK qvIGAdtyWN/O2kyeahoi9DGmET4PTyzccRddYRxTRhUONEHJPETs/ItIKGtPreZzskYJ 1HvRILFIPZo0lo3N6azdi/9ZrTEnARYCBu/sGQWHh/aJcgFje+gmejtGR8HOFGIVo0bt M9ITjjmrCaMNPGQOBER15nlklv9wIFJPqHTKfzsUPQehyt1Y9qvHxSCt9AcJ1VEsvT1g LH3A== X-Gm-Message-State: ALoCoQm6t/0xVyfMNpoNehS+XYqaSgv8dFp0Pi3/6lN23w9RT+Jp8hCiVTiRnClQif+Mf2bb4R1m X-Received: by 10.68.57.226 with SMTP id l2mr10866647pbq.1.1413426166879; Wed, 15 Oct 2014 19:22:46 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.23.208 with SMTP id 74ls554956qgp.17.gmail; Wed, 15 Oct 2014 19:22:46 -0700 (PDT) X-Received: by 10.52.138.211 with SMTP id qs19mr13271220vdb.13.1413426166180; Wed, 15 Oct 2014 19:22:46 -0700 (PDT) Original-Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [2607:f8b0:400c:c03::22b]) by mx.google.com with ESMTPS id p7si13860420vdi.19.2014.10.15.19.22.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 15 Oct 2014 19:22:45 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::22b as permitted sender) client-ip=2607:f8b0:400c:c03::22b; Original-Received: by mail-vc0-f171.google.com with SMTP id hy10so2004000vcb.30 for ; Wed, 15 Oct 2014 19:22:45 -0700 (PDT) X-Received: by 10.52.0.212 with SMTP id 20mr13342616vdg.30.1413426165572; Wed, 15 Oct 2014 19:22:45 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.220.65.138 with HTTP; Wed, 15 Oct 2014 19:22:45 -0700 (PDT) In-Reply-To: <997390c5-072b-407a-bce9-22a29fc5e228@isocpp.org> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c03::22b as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:13945 Archived-At: --047d7b86d52083e784050580ecfc Content-Type: text/plain; charset=UTF-8 On Wed, Oct 15, 2014 at 4:53 PM, Edward Catmur wrote: > N4191 provides that the fold of an empty parameter pack is defined for the > binary operators + * & | && || , to 0 1 0 -1 false true void() > respectively. I am concerned that this may result in confusing or undefined > behavior, especially for types that overload these operators. > > Consider string s = (to_string(args) + ...); if the 0 is the literal and > so can be interpreted as a null pointer constant this results in undefined > behavior, An empty pack fold-expression should never be considered to be a null pointer literal; thanks for pointing that out. > while if it is a prvalue int this gives a string of length 1 containing a > nul character. Yes, there's some risk this might happen accidentally. (If you anticipate the problem, you can write "auto s = (to_string(args) + ... + std::string());".) But it seems like a mistake that std::string implicitly converts from an int in a surprising way, and fixing that might be a better approach for this particular problem. > Other types give different errors; std::chrono::duration fails as its > constructor from int is explicit. > That's the same result you'd get with your proposed approach; I don't see a good way to address that. For binary * the library type valarray is unlikely to behave as desired; That case will give an error; the conversion from size_t is explicit. > similarly a square matrix type could give incorrect results. The binary > bitwise operators present a similar issue, and even for primitive types -1 > is likely to be of the wrong length and/or signedness (what happens when > 32-bit -1 is promoted to uint64_t?) > You get std::numeric_limits::max(), which seems like the right answer for this case. I would therefore argue to disallow empty parameter pack fold expansions > for the arithmetic and bitwise operators. This is a tricky convenience/safety tradeoff. I don't think the choice is obvious. We'll see what EWG thinks. The binary boolean operators and comma operator can stay; they are far less > often overloaded and the default values are simultaneously more obviously > correct and unique, more difficult to remember, and require more typing > than for the arithmetic and bitwise operators. > > Regards, Ed > > PS. If we are doing bitwise operators, what about ^? > The "simple" (no base case) forms exist for convenience, for types that act like the primitive types. A fold over ^ for primitive types doesn't seem likely to be useful in practice. But I wouldn't be opposed if there's a desire for it. PPS. Is ~ really supposed to be in there? Oops, no, it's not. -- --- 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/. --047d7b86d52083e784050580ecfc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Oct 15, 2014 at 4:53 PM, Edward Catmur <ed@catmur.co.uk> w= rote:
N4191 provides that the fold of an empty paramete= r pack is defined for the binary operators + * & | && || , to 0= 1 0 -1 false true void() respectively. I am concerned that this may result= in confusing or undefined behavior, especially for types that overload the= se operators.

Consider string s =3D (to_string(args) + ...); if the 0 is the literal and = so can be interpreted as a null pointer constant this results in undefined = behavior,

An empty pack fold-expressio= n should never be considered to be a null pointer literal; thanks for point= ing that out.
=C2=A0
while if it = is a prvalue int this gives a string of length 1 containing a nul character= ..

Yes, there's some risk this might hap= pen accidentally. (If you anticipate the problem, you can write "auto = s =3D (to_string(args) + ... + std::string());".) But it seems like a = mistake that std::string implicitly converts from an int in a surprising wa= y, and fixing that might be a better approach for this particular problem.<= /div>
=C2=A0
Other types give different erro= rs; std::chrono::duration fails as its constructor from int is explicit.

That's the same result you'= d get with your proposed approach; I don't see a good way to address th= at.

For binary * the library type vala= rray is unlikely to behave as desired;

That= case will give an error; the conversion from size_t is explicit.
=C2=A0
similarly a square matrix type could give inc= orrect results. The binary bitwise operators present a similar issue, and e= ven for primitive types -1 is likely to be of the wrong length and/or signe= dness (what happens when 32-bit -1 is promoted to uint64_t?)

You get std::numeric_limits<uint64_t>::max(), w= hich seems like the right answer for this case.

I would therefore argue to disallow empty parameter pack fold expansions fo= r the arithmetic and bitwise operators.

Thi= s is a tricky convenience/safety tradeoff. I don't think the choice is = obvious. We'll see what EWG thinks.

The binary boolean operators and comma operator can stay; they are far le= ss often overloaded and the default values are simultaneously more obviousl= y correct and unique, more difficult to remember, and require more typing t= han for the arithmetic and bitwise operators.

Regards, Ed

PS. If we are doing bitwise operators, what about ^?
<= br>
The "simple" (no base case) forms exist for conveni= ence, for types that act like the primitive types. A fold over ^ for primit= ive types doesn't seem likely to be useful in practice. But I wouldn= 9;t be opposed if there's a desire for it.

PPS. Is ~ really supposed to be in there?

O= ops, no, it's not.=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-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>.
--047d7b86d52083e784050580ecfc-- .