220 33013 article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: safe integrals comparison Date: Thu, 29 Jun 2017 08:10:34 +0200 Lines: 272 Approved: news@gmane.org Message-ID: References: <66f9bab2-7220-4bf1-afb7-77c5efa1bac3@isocpp.org> <6a3e0be1-3a7a-4cfd-a4a9-d49cd72bb52b@isocpp.org> <4fcbc46d-7754-1061-4c67-22ef74756fd2@wanadoo.fr> <47af44a1-4895-44da-b9af-090c75b53c37@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------14AAA5EF9C674F191D92619C" X-Trace: blaine.gmane.org 1498716640 13608 195.159.176.226 (29 Jun 2017 06:10:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 29 Jun 2017 06:10:40 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 To: std-proposals@isocpp.org, federico.kircheis@gmail.com Original-X-From: std-proposals+bncBDH67CONY4PBBXNT2LFAKGQEYY7E5CA@isocpp.org Thu Jun 29 08:10:34 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f72.google.com ([209.85.215.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dQSev-00038e-2h for gclcip-std-proposals@m.gmane.org; Thu, 29 Jun 2017 08:10:33 +0200 Original-Received: by mail-lf0-f72.google.com with SMTP id s20sf18759399lfe.7 for ; Wed, 28 Jun 2017 23:10:38 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1498716638; cv=pass; d=google.com; s=arc-20160816; b=wFdEICj3nKkwQMJTDoJUOcROoanDk9I4oLQP/7Mt4sOE8EztV+R2ozdaDwJ2f716tB TdeeM+OWJxddjQf/xTcvDsj/OYAIDPMJTgRPYOR0Z1heZ/aJ4J88ysTi81I8KDP4gPhg YEfr2QSkTH2qcXA3DcZrcho7qoku+0XZsDxmBTuNaDSvxC9KmxUM1E2SM78J69mWMfHE 5PoIsso9ZuqsVCEshF14AOtDcv+0AU5FwvP6QLAZlBVrKVaxjrm1+2CzIYvZ8hD+3uux ercZQwvdPS5Lh0cYKPbSMyjsWIbEWJjUmuGitcx0GSwkxvjDvHrVGNORCdtFtTJ7bq2c //Mw== 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:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:arc-authentication-results:arc-message-signature :dkim-signature:arc-authentication-results; bh=yd+FJQIb7wA82WMsbgUX3LB0/6TMEthldfUiiSKpYAw=; b=bC0h3BW7cRNMcjODYEXX4Qh9V+mkWKJviLUH3vJjqqVIyKK4jXGMb3MKnMnoCf4lMQ WLP7IpCHu81ngJm1Mzcu/t6DReMTK6VDdvwF5SUqUPQEIO0eq6qbkEPIxXiqqbNWU5v8 fSO/QaziHh8UR6GzOJZejpxHOOFQ83mC/MO1UGlDrFqGOYRVV49KGDlP3XeG27f3JP9s OrwVOsKUKzwE2jJLWhkBvD5Hll4i93zdz9ceEK7E2Cz5fXzLuuUFdLFenC5ZHSgjQ/j6 Bztp7SVR/ctsROuDbQmOkB0+eGIIIO0etVvKrSinMau5q0DMExn4+MWxR+cH4CuQ9uJx Ibvg== ARC-Authentication-Results: i=2; mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language: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=yd+FJQIb7wA82WMsbgUX3LB0/6TMEthldfUiiSKpYAw=; b=DPOYXDqLgS3utMWCDFK8SUGNkDIozAfVmAILnQdvLP/nX5Uu9qX4BvQ/IG7iudVcXT qQuTj16fTDZk7RyzNarT5AdaBImppgaW+WI6SjXDKMjeLCrSVZg62UbI2jjCv8aedkeD 4uceFdIa1neXpEwU4xeyADVNXXEQeK6v+/ehNb76ErT9ELUvo499/MoVLL+2h98LHrcb hn7WPBY1N8Fj/ks7+JK9khKYY68Djt1lYHKIRowPYtB3945MofcVUp9HybiPNkTSmioz xxo242bkNU4gNAngmZuU8fpt3/xS9LTEaAwNkKcoe3+6ekQD6bvXajOZ2jtN1lxqQ1i8 4FfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :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=yd+FJQIb7wA82WMsbgUX3LB0/6TMEthldfUiiSKpYAw=; b=rr7H4iI6Ce4mwBO/pqtPJw8iaksuMboQPymyUT+E5HH6P37mErezZNG992+sxMY6Q3 Q5cFpMIlPmgcZ+v99g5bmaHpCflfU6b0wmbOKwSPTDLvGexpFSUu4GNyrC9BK+xyW1Bx 1W96lJCGdC4BxLevCkvSIcietWWb4OrQyfwVZjILClqC98gSDITHyJPnmDNJ3Qe3wFLi JUyR9Y0+iY6KuOorN0NuU4/EjEufa4+0TIyTWRHa6/v0CWeUy//iCHtID8dxQ9ws9cyN z33vOnFffy/3kXXaoSS3oYyQfXTYlLy8lEjFX9vQ6raMT3BwxIHyrQmFi7MymU3ZCyxC W X-Gm-Message-State: AKS2vOx7t0NcL3z88ga+DYzMmLiyjnURK+RH4SkjVVi4lk3j9Nl7wFnL QN+BeKIhYliP9g== X-Received: by 10.25.211.8 with SMTP id k8mr360372lfg.2.1498716638085; Wed, 28 Jun 2017 23:10:38 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.87.213 with SMTP id l204ls43444wmb.15.gmail; Wed, 28 Jun 2017 23:10:36 -0700 (PDT) X-Received: by 10.28.225.133 with SMTP id y127mr9525179wmg.51.1498716636669; Wed, 28 Jun 2017 23:10:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1498716636; cv=none; d=google.com; s=arc-20160816; b=H6JgeXGqa67SYnxDo9E84P9rd7+YF9TFAFncaWwkmjg+CUXoqh6q1MRHC3N2HKvNnD Ze+W16LXaTEFNBb2JrGmDeDbyYNwYW+FyYXQ+3tDVuhCpXZesNebPERgYUQEGJvobfxm /FmNP1fseL7d5BHTbUlWHTBWW/p1p/nHExrRBCbPaBi995skJ8nCpnANvnQz5bDfQFbR VZBUH7pawYdfL2ZRTgUZnCuzAp9wkebu4XItuUFcbqZsAOKMmQ7w9UN5gZ9+RSUOxTRL +LTn4P0+UfzIRT9UMLgsUMRrxwktvQPIGbV141dZOlu9fLsvBYSyhms4k5DvFlSrQEhu OEBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:to:subject:arc-authentication-results; bh=+elv/H6/6Gcdy4shUPNk3X16gHr2tECyqMUQNzwVzf8=; b=X+B1ji6sd27ViBu2HD8e4lMvJVN39OsJRl9fEv1s7F7Xd2TCVDf4gw9Sp1C3Mmce8X v2eH0LGn5H5aeRNvyhah3dshIf3IiK9mWEi/o65BALK+wVIizEAuCZB6WhavzoANDfzB JjyZaA57T2tFA2kpQvzgI5vQZo7s+/Q1552dKq9Nk4HC3X0rGLcGmQ+WiH6ebE0+tdl0 0Qy9RgRsHIo89mAinzUPn9ekSPkut8brYFJh72ehJkSNY9GA8LvcrkctYM8BBfFr5bYz diLdErNHI0s0S+19ScNB2XdRRd4b/tKi9+4lYhqFkb0wE6IbHmqboizgMtYF8jjV4WHS PWvw== ARC-Authentication-Results: i=1; mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Original-Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr. [80.12.242.124]) by mx.google.com with ESMTPS id n82si7203695wma.15.2017.06.28.23.10.36 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 28 Jun 2017 23:10:36 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.124; Original-Received: from imac-de-vicente-botet-escriba.home ([86.253.36.96]) by mwinf5d25 with ME id eWAa1v00l24Tlo603WAbew; Thu, 29 Jun 2017 08:10:36 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Thu, 29 Jun 2017 08:10:36 +0200 X-ME-IP: 86.253.36.96 In-Reply-To: <47af44a1-4895-44da-b9af-090c75b53c37@isocpp.org> Content-Language: en-US X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:33013 Archived-At: This is a multi-part message in MIME format. --------------14AAA5EF9C674F191D92619C Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable Le 29/06/2017 =C3=A0 07:10, federico.kircheis@gmail.com a =C3=A9crit : > Hi, > >> One possible issue is that you may not know, between two types, >> which is the bigger one (for example inside a templated >> function). So a function like "can_be_narrowed" does not seem >> right because you are not going to narrow, whereas "in_range" >> does not have that issue -> seems more generic to me. >> > I don't see the difference. You can use narrow when the type is a > subset of the other. The implementation could be specialized to > just return true in this case? > > > It's more a naming issue, but nothing. With narrowing you expect to=20 > get s smaller type, that's all. Okay. Let name it narrow_if_needed if you prefer. > I wan't to stress that narrow_cast alone is not enough, we should=20 > have, like you have called it, a can_be_narrowed. Agreed. > IMHO narrow_cast should throw. I'm not against throwing, but it makes=20 > little sense if you already know how to handle that error, for example=20 > splitting you operation in multiple steps. I believe it is interesting to signal that we are narrowing even if we=20 know that in this context we don't loss information. The goal of=20 narrow_cast is just this. > > If you have for example a hash routine, with an update function, which=20 > length parameter is an int and not a size_t(happened to me moer than=20 > once), you can write your wrapper that takes the size_t, and if the=20 > value is bigger than numeri_limits__max() split the operation in=20 > multiple updates. > If you are casting immediately, you have to write less clear code=20 > IMHO. Therefore we should really have a function for checking the=20 > relative position of different integers.? I'm a little bit lost. Could you elaborate? > >> I cannot find any reference to the operator <=3D> >> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0100r2.htm= l >> ), >> do you have a link? > Sorry it was > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0515r0.pdf > > > Looks very interesting, I have mixed feelings about another operator=20 > for comparing value, but that behaves differently (even if in a more=20 > sensible way) with native types. > Is there some active discussion about it? If we would have such an=20 > operator, most of the functions I'm proposing will be unnecessary.=20 > I'ill add a reference, thank you. > I don't know of any active discussion. Maybe you can start it. > >> >> I would gladly drop the function "precision", but if you are >> comparing an unsigned type with a signed type, and both variables >> contains a positive value(!), how do you know if you need to cast >> them both to signed or to unsigned? If you do the comparison with >> std::numeric_limits without casting, an implicit conversion could >> give you an unexpected result (thats the whole point of this >> proposal). > My concern was to define a trait instead of a constexpr function, > but maybe we are going to constexpr functions now. > > > I've implemented it as a constexpr function, since I find it a lot=20 > easier to reason about it and use it (like I said, I'm not a template=20 > master), of course it can also be implemented as a trait, maybe I=20 > should mention it. Don't worry. It is clear this way. Vicente --=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/bcb5def9-0239-d0a4-faac-4921b404b1f6%40wanadoo.f= r. --------------14AAA5EF9C674F191D92619C Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Le 29/06/2017 =C3=A0 07:10, federico.kircheis@gmail.com a =C3=A9crit=C2=A0:
Hi,

One possible issue is that you may not know, between two types, which is the bigger one (for example inside a templated function). So a function like "can_be_narrowed" does not seem right because you are not going to narrow, whereas "in_range" does not have that issue -> seems more generic to me.

I don't see the difference. You can use narrow when the type is a subset of the other. The implementation could be specialized to just return true in this case?

It's more a naming issue, but nothing. With narrowing you expect to get s smaller type, that's all.
Okay. Let name it narrow_if_needed if you prefer.
I wan't to stress that narrow_cast alone is not enough, we should have, like you have called it, a can_be_narrowed.
Agreed.
IMHO narrow_cast should throw. I'm not against throwing, but it makes little sense if you already know how to handle that error, for example splitting you operation in multiple steps.
I believe it is interesting to signal that we are narrowing even if we know that in this context we don't loss information. The goal of narrow_cast is just this.

If you have for example a hash routine, with an update function, which length parameter is an int and not a size_t(happened to me moer than once), you can write your wrapper that takes the size_t, and if the value is bigger than numeri_limits<int>__max() split the operation in multiple updates.
If you are casting immediately, you have to write less clear code IMHO. Therefore we should really have a function for checking the relative position of different integers.?
I'm a little bit lost. Could you elaborate?
Looks very interesting, I have mixed feelings about another operator for comparing value, but that behaves differently (even if in a more sensible way) with native types.
Is there some active discussion about it? If we would have such an operator, most of the functions I'm proposing will be unnecessary. I'ill add a reference, thank you.

I don't know of any active discussion. Maybe you can start it.


I would gladly drop the function "precision", but if you are comparing an unsigned type with a signed type, and both variables contains a positive value(!), how do you know if you need to cast them both to signed or to unsigned? If you do the comparison with std::numeric_limits without casting, an implicit conversion could give you an unexpected result (thats the whole point of this proposal).
My concern was to define a trait instead of a constexpr function, but maybe we are going to constexpr functions now.

I've implemented it as a constexpr function, since I find it a lot easier to reason about it and use it (like I said, I'm not a template master), of course it can also be implemented as a trait, maybe I should mention it.
Don't worry. It is clear this way.

Vicente

--
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/bcb5def9-0239-d0a4-faac-4921b404b1f6= %40wanadoo.fr.
--------------14AAA5EF9C674F191D92619C-- .