220 29642 <22f8994a-11a8-4ecf-b11d-b8a902e4b9b3@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Anthony Hall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Class template argument deduction from class static functions Date: Sat, 3 Dec 2016 22:37:47 -0800 (PST) Lines: 335 Approved: news@gmane.org Message-ID: <22f8994a-11a8-4ecf-b11d-b8a902e4b9b3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_451_364012279.1480833467543" X-Trace: blaine.gmane.org 1480833471 32117 195.159.176.226 (4 Dec 2016 06:37:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 4 Dec 2016 06:37:51 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDQLJVXQ7EKBBPHTR3BAKGQEUP6QPFY@isocpp.org Sun Dec 04 07:37:46 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 1cDQQj-0007gy-TJ for gclcip-std-proposals@m.gmane.org; Sun, 04 Dec 2016 07:37:46 +0100 Original-Received: by mail-pg0-f70.google.com with SMTP id p66sf283879005pga.4 for ; Sat, 03 Dec 2016 22:37:49 -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: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=FTPgsSolvQ9EWVYspupaZvG+fvjkBvviQAqYYRHzuAI=; b=Y9MgemxmixjLjbaTE/Ez3CMh40bd8HGm+6aZoCaD5CxR2E9/GFM0JVCoXcLd8nOKjv 5AA1F0MqTbTkh5EIk3PTpaAtDQK0BANbQtlM6hWoB52p83N36ddD4LHPGFiPahYVUUa6 wc1Zmr7hRJKTQZpmHybglamOwMDb+zr8DyWD74sZG5upEpMi66Vj6hcqkA1MMoLD9TFH RqPMbmK90oWoA/MvA8mUfHjQloSd6kJ/om4y95C16Y5pdoeknBdfTTl5iCoPDEkxzB+D ykBT2Xdl9kqFGkx+Hc69tcxnVNddz4uxJ/wPm/4uiAQH9S7OUdDTHAFjR1isiXq65Kw7 +URg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=FTPgsSolvQ9EWVYspupaZvG+fvjkBvviQAqYYRHzuAI=; b=dI+JaHFAUhCHnIMCD35vvQ+FmlZeHK2YySG1JrXHQYs1Dly740sHx/FmmzMXQ0qp6O 2T5Am5CmKj3MRRmAGP0EByngP9FelD4XJOmggv0SgnbS2xDcYped0nJyDPIxFXZBk+T5 Vmtnpzou/yWJ1z8aDfXwvGV7knX1MQwc9eYX6n4kKtqfvLE5kydNKcjGr+zxOclpC8Rf UyfWl4Lg9vSlawT7Rdu+3GJUjIDq1imTijyfm3Z9mhir9H9kZDu730rA61NUVuZ9gnr1 I5lZr/0d+BT0Y1SYz3HieojKKXrxaYtZSAA8IVS+N6VxE61HyrkGjNr/QZ03WrVcF4x8 q5jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id: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=FTPgsSolvQ9EWVYspupaZvG+fvjkBvviQAqYYRHzuAI=; b=LrOIiTR69VOkI+S9urX5gyqQTOUk1UYunEz/Q51abm2VktTd+D7Tdr+USCJlOnZ7ZO 2O74WUCcURySCzwGUUaWdISiKTkZc8s8VlRgjsiJBDiB6PpfLeaCJBYexB5InfhczoLJ epVDKfZM4jCWkJAXJq04kmODe6rr3HJ9h+zhpJpA/px7TI3jq46pRyQPu9IbYtKZjT2N jgI12LFDQjAIGwCdkZKvrpLk0T2/f2qkStTEL1ZBZxJUXZ8DpHZZRC6pKikrFifsYXXH phr/vDlLdfNNGU/zdSSSGaBVj7OXrCu2KFLxHUQkaRUcrfSOIRlUoQW1y/uzENCJQUjj GueQ== X-Gm-Message-State: AKaTC00NdAkq+OSRyAL4A4V907+AxPEYhGehLy1u9SdaFf5PXoHcqIlDYmnBlMZ7wbIkCA== X-Received: by 10.99.94.67 with SMTP id s64mr24388222pgb.0.1480833469209; Sat, 03 Dec 2016 22:37:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.37.98 with SMTP id j31ls20950897otd.34.gmail; Sat, 03 Dec 2016 22:37:48 -0800 (PST) X-Received: by 10.157.17.167 with SMTP id v36mr3464727otf.12.1480833468316; Sat, 03 Dec 2016 22:37:48 -0800 (PST) X-Original-Sender: anthrond@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:29642 Archived-At: ------=_Part_451_364012279.1480833467543 Content-Type: multipart/alternative; boundary="----=_Part_452_751666331.1480833467544" ------=_Part_452_751666331.1480833467544 Content-Type: text/plain; charset=UTF-8 What if class template argument deduction, which we've gained in C++17, were extended to static class functions, not just constructors? For a personal project, I'm trying to enable this sort of deduction for constructors of a class wherever I can, but I've realized that for some ways of constructing a class instance I'd probably prefer to use the named constructor idiom, where a static class function returns an instance of the class by value. However, it occurs to me that I would then lose the convenience of the new class template argument deduction feature, since to my knowledge it has not been extended to work for static class functions as well. So, for example, as things are now in the working draft of C++17, to use this named constructor, I would have do something like the following: template< typename T, size_t N > struct Vector { std::array< T, N > components; template< typename ...S > requires sizeof...(S) == N && (std::is_convertible_v< S, T > && ...) // ^ (Using Concepts TS to constrain number and types of args, // but this is not central to this proposal) static Vector fromComponents( S &&...s ) { Vector v; v.components = { std::forward( s )... }; return v; } // ... }; // Here I have to give the template arguments to Vector explicitly, to specify // for which specialization of Vector 'fromComponents()' is being called auto vec = Vector::fromComponents( 0.74f, 0.74f, 0.0f ); It would be nice, however, if a deduction guide could be supplied for 'fromComponents', so that 'vec' could be initialized more simple: // Proposed deduction guide mechanism for class static functions template< typename ...S > Vector::fromComponents( S &&...s ) -> Vector< std::common_type< S... >, sizeof...(S) >; // Now, the deduction guide above makes the compiler able to deduce which // specialization of Vector to use, from the function arguments. auto vec = Vector::fromComponents( 0.74f, 0.74f, 0.0f ); I haven't given thought yet to how this would work for automatic deduction guides -- whether and how much sense that would make for static functions. For now I wanted to know if others think this looks like a useful direction for extending this feature, and is it something worth proposing for the standard? (I realize it's probably too late for c++17, but wondered if it still looks like something nice for future standards) P.S. I also just noticed that the example I gave was of a static function _template_ inside a struct template: it's interesting to me that in such a case the static function's arguments are being used to deduce the template arguments for _two_ entities: first the function template arguments themselves, then those for the surrounding struct. It makes me wonder if there are further generalizations of this notion of deducing the template arguments for one entity from arguments to another entity. I don't have any other concrete examples come to mind, but noticing that pattern just led me to wonder if there's some general abstraction trying to come out of all this. -- 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/22f8994a-11a8-4ecf-b11d-b8a902e4b9b3%40isocpp.org. ------=_Part_452_751666331.1480833467544 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What if class template argument deduction, which we&#= 39;ve gained in C++17, were extended to static class functions, not just co= nstructors? =C2=A0For a personal project, I'm trying to enable this sor= t of deduction for constructors of a class wherever I can, but I've rea= lized that for some ways of constructing a class instance I'd probably = prefer to use the named constructor idiom, where a static class function re= turns an instance of the class by value. =C2=A0However, it occurs to me tha= t I would then lose the convenience of the new class template argument dedu= ction feature, since to my knowledge it has not been extended to work for s= tatic class functions as well. =C2=A0

So, for exam= ple, as things are now in the working draft of C++17, to use this named con= structor, I would have do something like the following:

template< typename T, size_t N >
struct Vector {=
=C2=A0 =C2=A0= std::array< T, N > components;


=C2=A0 =C2=A0 template< typename = ....S >

=C2=A0 =C2=A0= requires = sizeof...(= S) =3D=3D N
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = &&= (std::is_convertible_v< S, T > && ...)
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 // ^ (= Using Concepts TS to constrain number and types of args,
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 // but= this is not central to this proposal)
=C2=A0 =C2=A0 static Vector fromComponents( S &&...s ) {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 Vector<= ;T<= span style=3D"color: #660;" class=3D"styled-by-prettify">, N> v;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 v.components =3D { std::forward= <S>( s )... };
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return v;
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0 // ...
};

// Here I have to give the template arguments to Vector explicitly, to= specify// for w= hich specialization of Vector 'fromComponents()' is being called
<= span style=3D"color: #008;" class=3D"styled-by-prettify">auto vec =3D Vector<float, 3<= /span>>::fromComponents<= /span>( 0.74f, 0.74f, 0.0f );

It would be nice, however, if a deduction= guide could be supplied for 'fromComponents', so that 'vec'= ; could be initialized more simple:

// Proposed deduction guide mec= hanism for class static functions
template< typename = ...= S >
Vector::fromComponents( S &&...s )= -> Vector< std::common_type< S... = >, sizeof<= span style=3D"color: #660;" class=3D"styled-by-prettify">...(S) >;

// Now, the deduction guide above makes the compiler able = to deduce which
/= / specialization of Vector to use, from the function arguments.
auto vec =3D Vector::fromComponents( 0.74f= , 0.74f, 0.0f );

I haven't give= n thought yet to how this would work for automatic deduction guides -- whet= her and how much sense that would make for static functions.

For now= I wanted to know if others think this looks like a useful direction for ex= tending this feature, and is it something worth proposing for the standard?= =C2=A0(I realize it's probably too late for c++17, but wondered if it = still looks like something nice for future standards)

<= div>P.S. I also just noticed that the example I gave was of a static functi= on _template_ inside a struct template: it's interesting to me that in = such a case the static function's arguments are being used to deduce th= e template arguments for _two_ entities: first the function template argume= nts themselves, then those for the surrounding struct. =C2=A0It makes me wo= nder if there are further generalizations of this notion of deducing the te= mplate arguments for one entity from arguments to another entity. =C2=A0I d= on't have any other concrete examples come to mind, but noticing that p= attern just led me to wonder if there's some general abstraction trying= to come out of all this.

--
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/22f8994a-11a8-4ecf-b11d-b8a902e4b9b3= %40isocpp.org.
------=_Part_452_751666331.1480833467544-- ------=_Part_451_364012279.1480833467543-- .