220 29999 <3490b351-9080-4fa1-af35-f43cb315d278@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: aary@umich.edu Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Return type deduction into a template parameter Date: Sat, 24 Dec 2016 07:50:23 -0800 (PST) Lines: 212 Approved: news@gmane.org Message-ID: <3490b351-9080-4fa1-af35-f43cb315d278@isocpp.org> References: <25614213-fc89-43e3-a17d-228fe01a9d01@isocpp.org> <2def9f74-1a39-405c-8ae3-87336d646ee2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2336_805005312.1482594623654" X-Trace: blaine.gmane.org 1482594630 10110 195.159.176.226 (24 Dec 2016 15:50:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 24 Dec 2016 15:50:30 +0000 (UTC) Cc: aary@umich.edu To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCB57BFXS4MRBQFS7LBAKGQEQB6U72I@isocpp.org Sat Dec 24 16:50:25 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f200.google.com ([209.85.217.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cKoaT-0001OX-PD for gclcip-std-proposals@m.gmane.org; Sat, 24 Dec 2016 16:50:22 +0100 Original-Received: by mail-ua0-f200.google.com with SMTP id v2sf39513485uac.0 for ; Sat, 24 Dec 2016 07:50:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=QHmGi8Me5JZ8QXx+HP71ryF7IgNeTsXES15D4Hf3sHA=; b=w1lbM8nrbXCq46v0bjjmHYK/oIxTmfIBw6yuMBBZVYs6ux2cx31n30likJj6O6ZSQi G94eegiXQS85G66bOl0Mvqp3G4d8GCyvmmfQjfE99UFRLZesNpFAbtGxfRmFWSJ9gPzC dAnMfmo94+CASuocfF6MaxILI+uQ3+7+hYvSD1eW8aPmjRxfgnuE/KllSqyhJuZtQhVM xWP7Y31kueLYuqbawATUBHKaQ51BlXt8VJc5wmwdoAJFb26GQhChxa9rD7J6J9NfktqA DJSJ9ZBew/6pdrn0ViJMO65kIgOjwJei87/Pd3/EmZwWVO6XCBmyjKIPd1kr5ybOrR1Y 40DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=date:from:to:cc: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=QHmGi8Me5JZ8QXx+HP71ryF7IgNeTsXES15D4Hf3sHA=; b=Hl5MN1tMU/1+r4Kf/P+aP18aeCNljle53THdPWdgy/alJ+c+jFSobkKo1Z3J9QmQ3a BwQwmiq4yxcB9jykda4SppuDULdZsbxbFLuovNMG+8qdfJyAsWTxorp/QOk3cRXMT6h+ ZQRJvViSmEOFLvW7YyMeTAkMLriFtPSKwPE2jErMq/Ow+p1YsfetX9X5Q3dMRE84sApE 3HIcAIE+JmR4Fkof3ZbeAAafRVpZbUNbTjdyZho92FTw+grloCzCsro3L5k480Abv1hm 8y/T0Qnwl/0bVUIqU/T/7pPj3y4nc0EyVT/XDToEmksDPhG+/GH3130s8z7Uv85/xueH aX9A== 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:cc: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=QHmGi8Me5JZ8QXx+HP71ryF7IgNeTsXES15D4Hf3sHA=; b=L4rMX27n1CjL6Lm54aGevg3l5WE49fz9yZc7NICqsF2Y2rkLUxnekA0qKFlekpyJw0 Vo/AoLvEhkt164X4SLHvS/Jt8su0JYkfAl+n8gA1B45BbbuAbuKD0VbM9z1daagdWWM+ i9OaQxX5xZ9VG6Zo/FJpd/14qfB5ePWFIHuJW8RFzcwwLtkRgfTOjvcIyAk6mZcVz4B2 +yqQqPdGOLW5MARfGuSELDTIKRBHdq1KpVvXwrAXLv/liHtrdv3Aofj0FI/zVhOS0J00 SMaZZ19/taPRtEPEMoXqUy/2PbXURZ6XKFbRNMiOquxgn3t0F9mjZG29wkbo8QtMloZb qTvw== X-Gm-Message-State: AIkVDXI65hZGA6zldhn3+Pn1XUrH2uZgGw4zitK3twkX+xWntP1TT/UNPjWvtBUs3l7Orw== X-Received: by 10.31.174.140 with SMTP id x134mr4011420vke.6.1482594625001; Sat, 24 Dec 2016 07:50:25 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.115 with SMTP id p48ls3217218otd.19.gmail; Sat, 24 Dec 2016 07:50:24 -0800 (PST) X-Received: by 10.157.51.88 with SMTP id u24mr261943otd.6.1482594624283; Sat, 24 Dec 2016 07:50:24 -0800 (PST) In-Reply-To: <2def9f74-1a39-405c-8ae3-87336d646ee2@isocpp.org> X-Original-Sender: aary@umich.edu 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:29999 Archived-At: ------=_Part_2336_805005312.1482594623654 Content-Type: multipart/alternative; boundary="----=_Part_2337_2049147615.1482594623654" ------=_Part_2337_2049147615.1482594623654 Content-Type: text/plain; charset=UTF-8 > > But since the implementation of such a function must be visible, what does > it matter? Just keep reading and look for the first `return` statement. That still requires the user to read the code and find the return statement, further the situation is complicated when the function is the last one in a chain of functions that return a value, in which case the user has to trace the return statements all the way to the first function that returned the actual type. Or alternatively use an IDE. But having this there still means that the language syntax is more clear to the reader. Classes don't have "instantiations". As such, it's not exactly clear what > `` is doing there. What I meant to say was that the object returned would be an an object of an instantiation of the class template with the type of the return parameter. I could not figure out how to edit my post :(. For instance if you consider the following code template class Interface { Interface(Type&& object_in) : object{std::forward(object_in) {} Type object; }; class Something { public: using value_type = int; }; Interface return_something(const Something& something) { return something::value_type{1}; } This would return an Interface object with the integer 1 as a member variable. I do not know whether this idea already exists built I thought this feature could be more flexible than just a concept, as it allows the usage of templates with the automatic return type deduction (which is an awesome idea), and does not require the use of trailing return types (which are verbose and sometimes not required). On Saturday, December 24, 2016 at 11:59:10 AM UTC+5:30, Nicol Bolas wrote: > > On Saturday, December 24, 2016 at 12:27:11 AM UTC-5, curious wrote: >> >> Hey guys, >> >> The proposal here is to allow the return type deduction syntax to be >> extendible to more versatile situations for example as a template >> parameter. Consider the following code >> >> template >> auto return_something(const Something& something); >> >> This interface gives the reader little to no information about what >> actually is being returned from the function, they have no way of knowing >> how they should go about interacting with the returned object. >> > > But since the implementation of such a function must be visible, what does > it matter? Just keep reading and look for the first `return` statement. > > If instead something like the following could be done >> >> // in the .hpp file, this is the declaration of the function, exposing >> useful >> // information to the user about the return type of the function, they now >> // know that they can interact with the return type every way that the >> // SomeInterfaceOrConcept class can be used. >> template >> SomeInterfaceOrConcept return_something(const Something& something); >> >> Now the reader instantly knows that the return type is an instantiation >> of the SomeInterfaceOrConcept class, >> > > Classes don't have "instantiations". As such, it's not exactly clear what > `` is doing there. If you want concepts to be able to replace > placeholders in return type deduction, `` is meaningless; just use > the concept name itself, as with any other concept placeholder. And if > `SomeInterfaceOrConcept` is an actual class, then `` is a compile > error. > > So what exactly is this supposed to do? > -- 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/3490b351-9080-4fa1-af35-f43cb315d278%40isocpp.org. ------=_Part_2337_2049147615.1482594623654 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But since the implementation = of such a function must be visible, what does it matter? Just keep reading = and look for the first `return` statement.
That still requires = the user to read the code and find the return statement, further the situat= ion is complicated when the function is the last one in a chain of function= s that return a value, in which case the user has to trace the return state= ments all the way to the first function that returned the actual type. =C2= =A0Or alternatively use an IDE. =C2=A0But having this there still means tha= t the language syntax is more clear to the reader. =C2=A0

Classes don't have "instantiations&= quot;. As such, it's not exactly clear what `<auto>` is doing the= re.
What I meant to say was that the object returned would= be an an object of an instantiation of the class template with the type of= the return parameter. =C2=A0I could not figure out how to edit my post :(.= =C2=A0For instance if you consider the following code=C2=A0
=
template <typename = Type>
class Inter= face {
=C2=A0 =C2=A0= Interface(Type&& object_in) : object{std::forward<Type>(obje= ct_in) {}
=C2=A0 =C2= =A0 Type object;
};<= /font>

class Something {
= public:
=C2=A0 =C2=A0 using value_type =3D int;<= /div>
};

Interface<auto> return_somet= hing(const Something& something) {
=C2=A0 =C2=A0 return something::value_type{1};
}

This would return an Interface object with the integer 1 as a m= ember variable. =C2=A0I do not know whether this idea already exists built = I thought this feature could be more flexible than just a concept, as it al= lows the usage of templates with the automatic return type deduction (which= is an awesome idea), and does not require the use of trailing return types= (which are verbose and sometimes not required).=C2=A0

On Saturday, December 24, 2016 at 11:59:10 AM UTC+5:30, Nicol Bolas wr= ote:
On Saturd= ay, December 24, 2016 at 12:27:11 AM UTC-5, curious wrote:
Hey guys,

The pr= oposal here is to allow the return type deduction syntax to be extendible t= o more versatile situations for example as a template parameter. =C2=A0Cons= ider the following code

template <typename Something>
auto return_something(const Something& some= thing);

<= /div>
This interface gives the reader = little to no information about what actually is being returned from the fun= ction, they have no way of knowing how they should go about interacting wit= h the returned object.

But since th= e implementation of such a function must be visible, what does it matter? J= ust keep reading and look for the first `return` statement.

If instead something like the following could be done

<= font face=3D"courier new, monospace">// in the .hpp file, this is the decla= ration of the function, exposing useful
// information to the user about the return type of= the function, they now
// know that they can interact with the return type every way that the<= /font>
// SomeInterfaceOrCo= ncept class can be used. =C2=A0
template <typename Something>
SomeInterfaceOrConcept<auto> return_somet= hing(const Something& something);

Now the reader instantly knows that the r= eturn type is an instantiation of the SomeInterfaceOrConcept clas= s,

Classes don't have "ins= tantiations". As such, it's not exactly clear what `<auto>` = is doing there. If you want concepts to be able to replace placeholders in = return type deduction, `<auto>` is meaningless; just use the concept = name itself, as with any other concept placeholder. And if `SomeInterfaceOr= Concept` is an actual class, then `<auto>` is a compile error.
So what exactly is this supposed to do?

--
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/3490b351-9080-4fa1-af35-f43cb315d278= %40isocpp.org.
------=_Part_2337_2049147615.1482594623654-- ------=_Part_2336_805005312.1482594623654-- .