220 30040 <0cfcac6f-4d8a-40f2-9fc7-cf82c65db117@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: decltype(return) Date: Tue, 27 Dec 2016 07:04:45 -0800 (PST) Lines: 189 Approved: news@gmane.org Message-ID: <0cfcac6f-4d8a-40f2-9fc7-cf82c65db117@isocpp.org> References: <658f00ff-7a02-7c04-3fcb-6ac7f45b777b@scylladb.com> <425f6577-b92d-40f3-8d0d-64668351edf5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1043_1940871803.1482851085850" X-Trace: blaine.gmane.org 1482851093 11670 195.159.176.226 (27 Dec 2016 15:04:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Dec 2016 15:04:53 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBDUGRLBQKGQEVCG6ZYI@isocpp.org Tue Dec 27 16:04:45 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pg0-f70.google.com ([74.125.83.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cLtIw-0001m7-Sk for gclcip-std-proposals@m.gmane.org; Tue, 27 Dec 2016 16:04:43 +0100 Original-Received: by mail-pg0-f70.google.com with SMTP id f188sf1003392133pgc.1 for ; Tue, 27 Dec 2016 07:04:47 -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: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=fZBk/qRI8woR7RIy8eWq/zRPdwj27UnMcKUCJgNGk0s=; b=UmcZRLFd60KCP5IT9KlVnDPj7znk6Jf8kusXhzK1Zl+5JzYQTllKE1DewbnfVeulRm wTwkvdjgQ6nRqYF83eMkNhAQwDZTb6VVN1MNtd+GzkVhzZKTWkuMoVNGt5n37tEa3/Q/ MbjMb3g4NxGJnd3+sVFCswFopJNFhCBKuDnT4uCv4ToU7mALnXB7JsJaWrDBtCDMi1Eb 7WmzEhRUpIPQ0vYln1nK1BOqg3SXBbWZywZ3Ht1JPjCyHbkz1Fheh5HZ2a0E8WVo0SR/ dD49aLDq4bbKvrVy1m70d0qye7L5kjVP36MEQVKWzecmk9Yde+EzZxiBm8/2ypZNybD1 IO5w== 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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=fZBk/qRI8woR7RIy8eWq/zRPdwj27UnMcKUCJgNGk0s=; b=euMkt7+C+5aKF5vifpNVEhhRcwlKh3Ki72lGnspC/F9VXeS0BLZ2QTWhykafG04u7b PhJqWODVga7H/qTZ+tEZo21XIT8+JH/Mr9ZJPLHpf0ej4XntRDUYCInPZqZku4sK7j57 QrrvIvS0Hat3QKdf/bkI8RMshpxe4KmmIdn6vF1yVsQ2uk4NzhoHqelYMj3MLA6jFCss p2ZMkqhSg7X//YzVvN6UGQXb8iy2DASvAnZgiYClFXRxvBiSyfb7uZ/ekSQDUCCXDhLp vNiLmZ1cK76KDSha/0gR64B9ia5RL82s/t2Rz2D5mAuA9+Iuj7TaZrVhQFk0fsaDbXLy 7mcw== 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=fZBk/qRI8woR7RIy8eWq/zRPdwj27UnMcKUCJgNGk0s=; b=Xjwoi4dDIrw+DO+7z/jJIlMDLswb+dq6JX/LOFfeS3Dq/aFqDL/PegtYS1fZT9jdQZ IuZ0x+BVcy297pslVhH/KRuvwb911J3CeiB5lONGaRobxq5jL7G1jzkfsgr0AeSIdduG 1YLX8PrZuibdhjWvW2PX+hFbR8JZTWCgNU3QvhsYL7fIgrmmiYujKw4bJVFJ9ujXP/NJ sJf37yOm244jRZsLKnodqYppYAUmZJYQX/20gToFMwe56RznnIKazQe2kTiF+KlpylQL JUvXZkHfXXn/lijFz22I7nCpxJNZmtXkQKLJjFQvnvfcaqctITu+k4NJOMA37PHQe0nt 3T8g== X-Gm-Message-State: AIkVDXLRxmzNw9dYt8pznVMTJC9qwLh/FCJyRUN31MN65fL64NejFXxoG21ufqt1O8TJzA== X-Received: by 10.99.184.18 with SMTP id p18mr19180618pge.126.1482851087180; Tue, 27 Dec 2016 07:04:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.43.168 with SMTP id u37ls22667771ota.29.gmail; Tue, 27 Dec 2016 07:04:46 -0800 (PST) X-Received: by 10.157.49.66 with SMTP id v2mr1610461otd.19.1482851086379; Tue, 27 Dec 2016 07:04:46 -0800 (PST) In-Reply-To: X-Original-Sender: jmckesson@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:30040 Archived-At: ------=_Part_1043_1940871803.1482851085850 Content-Type: multipart/alternative; boundary="----=_Part_1044_2021313351.1482851085850" ------=_Part_1044_2021313351.1482851085850 Content-Type: text/plain; charset=UTF-8 On Tuesday, December 27, 2016 at 12:43:11 AM UTC-5, Antony Polukhin wrote: > > 2016-12-25 22:27 GMT+03:00 Nicol Bolas >: > > > > > > On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, Antony Polukhin wrote: > >> > >> 2016-11-18 19:01 GMT+03:00 Avi Kivity : > >> > > >> > map, baz>> > >> > complicated(...) { > >> > decltype(return) ret; > >> > // add stuff to ret > >> > return try; > >> > } > >> > > >> > Instead of repeating the complicated type, refer to it via > >> > decltype(return). > >> > Won't work with deduced return types, of course. > >> > >> Syntax sugar makes the language harder to understand. > > > > > > No, it doesn't. `for` loops are syntactic sugar for `while` loops. > > Range-based `for` loops are syntactic sugar for `for` loops over the > > begin/end iterators. And technically, you could implement all of those > with > > `goto`. > > All that sugar exist in many popular languages. decltype(return) does not. > My overall point was that your statement "Syntax sugar makes the language harder to understand," is wrong. "many popular languages" don't have typenames that are as large as C++ typenames can get. What other languages do or don't do is not by itself sufficient justification for what C++ should do or not do. You can argue that it makes code harder to understand. I don't agree that this is sufficient to warrant not having this feature, but you can argue it. But arguing that we shouldn't have feature just because other languages don't doesn't make sense. We're not making "many popular languages"; we're making C++. Languages are not supposed to be carbon copies of each other. > That depends on how many lines it takes to enter that return type. After > > all, you can use `decltype(return)` even in a function that deduces its > > return type from a return statement. So that return type could be quite > > lengthy. > > It's already hard to understand what is happening if there's multiple > chained functions with auto return type. Adding decltype(return) may > make the things wose. > > >> motivates people to write ugly return types instead of providing a > >> humanreadable typedef for the result type: > > > > > > You assume that such a typedef can actually be written. Automatic return > > type deduction means that types with very complex typenames can be > returned. > > Not all of them can be easily predicted and culled out with a typedef. > > Could you give an example? > A lot of the stuff in Boost.Spirit, for example. What is the return type of a complex expression of Spirit parsers? -- 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/0cfcac6f-4d8a-40f2-9fc7-cf82c65db117%40isocpp.org. ------=_Part_1044_2021313351.1482851085850 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, December 27, 2016 at 12:43:11 AM UTC-5, Antony= Polukhin wrote:
2016-12-25 22:= 27 GMT+03:00 Nicol Bolas <jmck...@gmail.com>:
>
>
> On Sunday, December 25, 2016 at 2:13:57 PM UTC-5, Antony Polukhin = wrote:
>>
>> 2016-11-18 19:01 GMT+03:00 Avi Kivity <a...@scylladb.com= >:
>> >
>> > map<foo, map<set<bar>, baz>>
>> > complicated(...) {
>> > =C2=A0 =C2=A0 decltype(return) ret;
>> > =C2=A0 =C2=A0 // add stuff to ret
>> > =C2=A0 =C2=A0 return try;
>> > }
>> >
>> > Instead of repeating the complicated type, refer to it vi= a
>> > decltype(return).
>> > Won't work with deduced return types, of course.
>>
>> Syntax sugar makes the language harder to understand.
>
>
> No, it doesn't. `for` loops are syntactic sugar for `while` lo= ops.
> Range-based `for` loops are syntactic sugar for `for` loops over t= he
> begin/end iterators. And technically, you could implement all of t= hose with
> `goto`.

All that sugar exist in many popular languages. decltype(return) does n= ot.

My overall point was that your statement "= ;Syntax sugar makes the language harder to understand," is wrong.
<= br>"many popular languages" don't have typenames that are as = large as C++ typenames can get. What other languages do or don't do is = not by itself sufficient justification for what C++ should do or not do.
You can argue that it makes code harder to understand. I don't agr= ee that this is sufficient to warrant not having this feature, but you can = argue it. But arguing that we shouldn't have feature just because other= languages don't doesn't make sense. We're not making "man= y popular languages"; we're making C++.

Languages are not s= upposed to be carbon copies of each other.

> That depends on how many lines it takes to enter that return type. Aft= er
> all, you can use `decltype(return)` even in a function that deduce= s its
> return type from a return statement. So that return type could be = quite
> lengthy.

It's already hard to understand what is happening if there's mu= ltiple
chained functions with auto return type. Adding decltype(return) may
make the things wose.

>> motivates people to write ugly return types instead of providi= ng a
>> humanreadable typedef for the result type:
>
>
> You assume that such a typedef can actually be written. Automatic = return
> type deduction means that types with very complex typenames can be= returned.
> Not all of them can be easily predicted and culled out with a type= def.

Could you give an example?

A lot of the stuff = in Boost.Spirit, for example. What is the return type of a complex expressi= on of Spirit parsers?

--
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/0cfcac6f-4d8a-40f2-9fc7-cf82c65db117= %40isocpp.org.
------=_Part_1044_2021313351.1482851085850-- ------=_Part_1043_1940871803.1482851085850-- .