220 34495 <072abf8e-251c-4fe5-a24f-80c9319e3326@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: "T. C." Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Auto return type deduction surprises Date: Tue, 26 Sep 2017 12:04:01 -0700 (PDT) Lines: 164 Approved: news@gmane.org Message-ID: <072abf8e-251c-4fe5-a24f-80c9319e3326@isocpp.org> References: <7bf0d2563477e89a8faa3ca2daa18f67@kdab.com> <25067783-13f0-4943-9736-f7326f1567d7@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7590_806092240.1506452641806" X-Trace: blaine.gmane.org 1506452644 30834 195.159.176.226 (26 Sep 2017 19:04:04 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 26 Sep 2017 19:04:04 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCQ43G7NQIIRBIWJVLHAKGQEWKZZ5NA@isocpp.org Tue Sep 26 21:04:00 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f199.google.com ([209.85.192.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dwv9B-0007YF-BP for gclcip-std-proposals@m.gmane.org; Tue, 26 Sep 2017 21:03:57 +0200 Original-Received: by mail-pf0-f199.google.com with SMTP id b70sf4598656pfl.16 for ; Tue, 26 Sep 2017 12:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=zovcKwYIRguxq5wbXhF4vPdtOEDxw9F3wnrqIcNuE3I=; b=La8Zctm44TQrPHpy1s4eXvHjUVVthrc9FVX3fjhlV57At6PlSvl7IninVA+y5po+Aj wBJ1fuM8+Wv+33G1jE7V9atbtFknS8o2N//MtfOSmVBarD9gRbUhq9LX4cxZV7Ad6di2 wIulifwvx0LuNxUUjhCA5QDc2D2ALvxrHhxZtfgYZ5CDjivI3Q2aTAsDuPiQu5wQCJeh Zux0fkh/q5CYAS82JDU6vhqPVEq4S4bFd1ctFkY2eqetpDh4LbIpSnWdss5HvFhWSrdk HJ/P3b7e8VGrPVWZdWedlRT1UiPuATuMt9LSFxqQeE55Hi5ycild60SS2EBx3du2uXHp DZmA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=zovcKwYIRguxq5wbXhF4vPdtOEDxw9F3wnrqIcNuE3I=; b=pzrNYHhE8wvquex59VJHOQvIqkPX5C/oepnet/joDRpidyik1aH6ythhkNyz29A3Id oqTpObLoWT46XS1vR/hAfPpH34YcffQbNaALV8WRkakGevZiyunVvM0PErlvwf7lNvkb WB2wOBYtqBGP3xvwBuPNxM+cunGIQmfyAkWzW/yg+eAgnUCRjjtC+N6b6SumTAMvlR4v IupZUI5WKMm8+X6vIrYBn4ONKQXRj00GBdKsR7PbImEsj183rkwCUxQKDvvb6wvKnTvB wrq2nCnSu+KeIVRoSrgTflrmCZIhnOboXBTNJY8MKjgapqlSiSIgIVsnxqxdARckwMqH Lmrg== 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:in-reply-to:references :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=zovcKwYIRguxq5wbXhF4vPdtOEDxw9F3wnrqIcNuE3I=; b=m8L3IFH+cVaQu4SfhmVDRQPsm1HEH2FHBQF+RkT3Oi52ud5+oS94I76AXbPzAWkN5X R0VW3Ci6IUk7/RFWeQ9HlI621vCixFLcl6h/l5EIQtObnG6x36/A4aPXFjPAiJsm6/uP bWnlUd0nxuqnOIFbRijnjc77buKkYJF3HLSEFOBHprssih8pp13EoQZl1WkdSej7AZQL 3TU6YPKlz/seeMpzSpBxwBfqsV8SLe2qD4IpZYQEyLsYqdaZSYg1kMPU/uNiN7pwWadM 8FHf8YKsIUtHF6zjuGn4Bzi4E8uiQlIPldNCVhAe7gF8gPUiZ2TRTnve/Vuh1cbyyOkW xk7Q== X-Gm-Message-State: AHPjjUgE+y6pKnjuV8GHwQMtvYIdHIM4U3Gg0/1qWTeOmvaUJcDUFilx nMfY4OBkLnR9Byil/bynCRZpcg== X-Google-Smtp-Source: AOwi7QDoeOztwAevAGTCL9LTXvuZy1dE27BgncZGke6xQhAuHNuPBozrzeu2+sNtZzPRgAvmU9fHqw== X-Received: by 10.99.178.30 with SMTP id x30mr7508104pge.113.1506452644303; Tue, 26 Sep 2017 12:04:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.188.207 with SMTP id m198ls148967vkf.21.gmail; Tue, 26 Sep 2017 12:04:02 -0700 (PDT) X-Received: by 10.31.178.23 with SMTP id b23mr431005vkf.14.1506452642414; Tue, 26 Sep 2017 12:04:02 -0700 (PDT) In-Reply-To: <25067783-13f0-4943-9736-f7326f1567d7@isocpp.org> X-Original-Sender: rs2740@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:34495 Archived-At: ------=_Part_7590_806092240.1506452641806 Content-Type: multipart/alternative; boundary="----=_Part_7591_1303224052.1506452641806" ------=_Part_7591_1303224052.1506452641806 Content-Type: text/plain; charset="UTF-8" On Tuesday, September 26, 2017 at 11:21:35 AM UTC-4, Nicol Bolas wrote: > > On Tuesday, September 26, 2017 at 4:54:21 AM UTC-4, Richard Smith wrote: >> >> On 26 September 2017 at 00:53, Marc Mutz wrote: >> >>> Hi, >>> >>> Why do these semantically identical pieces of code have different syntax >>> rules? >>> >>> template >>> auto find(Map &map, const Lookup &key) >>> { >>> const auto it = map.find(key); >>> if (it == map.end()) >>> return std::nullopt; >>> else >>> return std::optional{*it}; // error: inconsistent deduction >>> for auto return type >>> } >>> >>> template >>> auto find(Map &map, const Lookup &key) >>> { >>> const auto it = map.find(key); >>> return it == map.end() ? std::nullopt : std::optional{*it}; // OK, >>> -> std::optional >>> } >>> >>> iow: Why do auto return types have to have identical types, and don't >>> just use the rules for the ternary operator? >>> >> >> Because some people thought it more important to allow self-recursive >> calls after the first return statement: >> >> auto f(int n) { >> if (n <= 1) return 1; >> return n * f(n - 1); // ok to call f here, return type already deduced >> } >> >> FWIW, I think we made the wrong tradeoff here, but this decision is >> unlikely to be reconsidered now. >> > > Personally, I think it's a good move. Not for self-recursion reasons but > for sanity and error checking reasons. > > With the ?: operator, the two expressions are right next to each other. > This means that if you can see one expression, you can see the other. As > such, you can easily see from that one line what the overall expression > resolves to. It requires more mental thought, but all of the information is > right there in the same statement. > > Return statements can be *pages* apart, depending on function length. As > such, it's much more difficult to know what `std::common_type` will resolve > to; figuring that out requires bouncing between all of the return > statements in the function. So in order to know what the function's return > type is, you have to read the *entire* thing. > Also, we won't be able to use common_type's semantics, which is order dependent for >2 arguments. That would be insane for this case. We'd have to generalize ?:'s semantics directly for >2 operands if we want to go down that path. -- 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/072abf8e-251c-4fe5-a24f-80c9319e3326%40isocpp.org. ------=_Part_7591_1303224052.1506452641806 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, September 26, 2017 at 11:21:35 AM UTC-4, Nicol= Bolas wrote:
= On Tuesday, September 26, 2017 at 4:54:21 AM UTC-4, Richard Smith wrote:
On 26 September 2017 at 00:53, Marc Mutz <<= a rel=3D"nofollow">marc...@kdab.com> wrote:
Hi,

Why do these semantically identical pieces of code have different syntax ru= les?

=C2=A0 template <typename Map, typename Lookup>
=C2=A0 auto find(Map &map, const Lookup &key)
=C2=A0 {
=C2=A0 =C2=A0 =C2=A0 const auto it =3D map.find(key);
=C2=A0 =C2=A0 =C2=A0 if (it =3D=3D map.end())
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::nullopt;
=C2=A0 =C2=A0 =C2=A0 else
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return std::optional{*it}; // error: inc= onsistent deduction for auto return type
=C2=A0 }

=C2=A0 template <typename Map, typename Lookup>
=C2=A0 auto find(Map &map, const Lookup &key)
=C2=A0 {
=C2=A0 =C2=A0 =C2=A0 const auto it =3D map.find(key);
=C2=A0 =C2=A0 =C2=A0 return it =3D=3D map.end() ? std::nullopt : std::optio= nal{*it}; // OK, -> std::optional<Map::value_type>
=C2=A0 }

iow: Why do auto return types have to have identical types, and don't j= ust use the rules for the ternary operator?

=
Because some people thought it more important to allow self-recursive = calls after the first return statement:

auto f(int= n) {
=C2=A0 if (n <=3D 1) return 1;
=C2=A0 return n= * f(n - 1); // ok to call f here, return type already deduced
}<= /div>

FWIW, I think we made the wrong tradeoff here, but= this decision is unlikely to be reconsidered now.
<= /blockquote>

Personally, I think it's a good move. N= ot for self-recursion reasons but for sanity and error checking reasons.

With the ?: operator, the two expressions are right = next to each other. This means that if you can see one expression, you can = see the other. As such, you can easily see from that one line what the over= all expression resolves to. It requires more mental thought, but all of the= information is right there in the same statement.

=
Return statements can be pages apart, depending on function len= gth. As such, it's much more difficult to know what `std::common_type` = will resolve to; figuring that out requires bouncing between all of the ret= urn statements in the function. So in order to know what the function's= return type is, you have to read the entire thing.

Also, we won't be able to use common_type&#= 39;s semantics, which is order dependent for >2 arguments. That would be= insane for this case.

We'd have to generalize= ?:'s semantics directly for >2 operands if we want to go down that = path.

--
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/072abf8e-251c-4fe5-a24f-80c9319e3326= %40isocpp.org.
------=_Part_7591_1303224052.1506452641806-- ------=_Part_7590_806092240.1506452641806-- .