220 18756 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Factory functions as deducing constructors? (N4471) Date: Wed, 24 Jun 2015 16:59:06 -0700 Lines: 300 Approved: news@gmane.org Message-ID: References: <9A3E0561DCF227429F72080EA81ADBC96077F5170F@TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec5489e45cbcbb305194c4a26 X-Trace: ger.gmane.org 1435190350 18690 80.91.229.3 (24 Jun 2015 23:59:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 24 Jun 2015 23:59:10 +0000 (UTC) Cc: David Krauss , "std-proposals@isocpp.org" To: Michael Spertus Original-X-From: std-proposals+bncBDVNBJG4YAIBBS4IVWWAKGQEC7BGQHA@isocpp.org Thu Jun 25 01:59:09 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Z7uZQ-0007Ix-OQ for gclcip-std-proposals@m.gmane.org; Thu, 25 Jun 2015 01:59:09 +0200 Original-Received: by qcfx5 with SMTP id x5sf42499859qcf.3 for ; Wed, 24 Jun 2015 16:59:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type: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=v5YHw3Ho8AMMQezzSwT9rvKvbD9u+Z+JhiVrpTgRDR8=; b=CjX61N7Mslrw1mlmdOwlgtFXY1Rr1LlW5jwFfmn8I5gWI1yD9VZK81BNUaDBcsK1JG aOUGEJyaphDLHQDQ6yT1OlmpjkEHDDdrkTF1LLPLdOzQA+Kj0upy7LzDT7hRA8Cc+PEx cCNplgsuSdC7kA7mhv1RBvCTarj0MeXSHn6v9K2FS4lm7vc+vUyhAhpsGj1beYztAL8D VaGeS0aZQexmDBhsCDEbi7jXcOfFysZ0GK5y99qzmKCK6JU+7Q6WD6Pjj1zkjspd/gmS ySo7iZNVkBdSRUzOP2Z7PcF4DfywxT+GYDdX9mXpCIzZOvKn5YwiEJA+eQGzPJoG3Hd6 Uu6Q== X-Gm-Message-State: ALoCoQkaQ/CKhrsfjbYRjGFQpuoK3FditrGquAEYxw23emulXcAZQZyaOkaEFRP+RuUdeslyOHbf X-Received: by 10.52.28.5 with SMTP id x5mr56239925vdg.3.1435190347814; Wed, 24 Jun 2015 16:59:07 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.27.193 with SMTP id 59ls1009261qgx.22.gmail; Wed, 24 Jun 2015 16:59:07 -0700 (PDT) X-Received: by 10.52.136.239 with SMTP id qd15mr25652166vdb.89.1435190346934; Wed, 24 Jun 2015 16:59:06 -0700 (PDT) Original-Received: from mail-vn0-x22f.google.com (mail-vn0-x22f.google.com. [2607:f8b0:400c:c0f::22f]) by mx.google.com with ESMTPS id tt20si26362743vdb.78.2015.06.24.16.59.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 16:59:06 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c0f::22f as permitted sender) client-ip=2607:f8b0:400c:c0f::22f; Original-Received: by vnbg129 with SMTP id g129so8683581vnb.2 for ; Wed, 24 Jun 2015 16:59:06 -0700 (PDT) X-Received: by 10.52.114.230 with SMTP id jj6mr26368664vdb.66.1435190346630; Wed, 24 Jun 2015 16:59:06 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.31.75.2 with HTTP; Wed, 24 Jun 2015 16:59:06 -0700 (PDT) In-Reply-To: <9A3E0561DCF227429F72080EA81ADBC96077F5170F@TUS1XCHEVSPIN42.SYMC.SYMANTEC.COM> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c0f::22f as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:18756 Archived-At: --bcaec5489e45cbcbb305194c4a26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jun 24, 2015 at 2:55 PM, Michael Spertus wrote: > Hi David, > > That sounds to me essentially like the factory functions part of the > proposal except you allow bodies in them. Is that correct? We explicitly > rejected that because I felt that the body belonged in the class and was > consistent with C++=E2=80=99 traditional values about what should be in t= he class > definition (Although I can=E2=80=99t speak for Richard=E2=80=99s motivati= on, he also > explicitly forbid defining the body). > I arrived at the current "guiding declarations" approach as a special case of a more general mechanism. Sometimes you want a function template that has some non-trivial way of computing its desired parameter types from the types of its arguments. This can't be done in today's C++: if you capture your argument types through deduction, your parameter types must exactly match the argument types. So the feature I was considering would allow this= : template void f_impl(maybe_add_ref...); template some_keyword_maybe f(Args...) -> f_impl; The second declaration is a deduction guide: it says, when you see a call f(blah), and that function is the best viable function, then proceed as if f were replaced by f_impl. And for constructors: template some_keyword_maybe vector(initializer_list) -> vector; .... says essentially the same thing: when you see vector{1, 2, 3}, if that declaration is the best viable function (say, with T =3D int), then 'vector= ' really means 'vector'. One reason why you would want something like this instead of giving a definition to the constructor (or function template) is to avoid duplication -- you already have the constructor definition, and shouldn't be repeating it in the way the old make_-function pattern forced you to. Another reason is to avoid unnecessary copies / moves of function arguments= .. > A point in favor of your approach is that Bjarne=E2=80=99s unified funct= ion call > syntax proposal is to support =E2=80=9Cexternally defined methods=E2=80= =9D but doesn=E2=80=99t work > for constructors. > > > > I plan to start looking at the next revision in about a month. OK if we > discuss then? > > > > Thanks, > > > > Mike > > > > *From:* David Krauss [mailto:potswa@gmail.com] > *Sent:* Wednesday, June 24, 2015 4:45 AM > *To:* Michael Spertus; std-proposals@isocpp.org > *Cc:* Richard Smith > *Subject:* Factory functions as deducing constructors? (N4471) > > > > Hi Mike, > > > > Most libraries already implement factory function templates, e.g. > make_thing(). Why not just let them be named e.g. thing(), aliasing the > class template? > > > > - No new deduction rules are needed. > - It=E2=80=99s a non-breaking change because such aliasing is currentl= y > disallowed. > - It differs from established practice only by renaming. > - The full flexibility of factory functions is preserved, including > explicit template arguments. > - It does not intrude into the class template implementation. > > > > For the sake of member templates, such a function template (or function) > should still be found by a qualified-id preceded by the typename keyword. > It should also be illegal to take its address, or to do anything with its > name or template-id besides call it. The factory should defer to real > constructors when the explicit template argument list satisfies the class > template parameters. > > > > Require the factory to be declared after the initial declaration of the > class template, and require its return type to be a specialization. > > > > Implementation model: Attach the overload set of factory functions to the > class template. When name lookup finds the class template, grab the > factories too. If template arguments are provided, treat the class templa= te > as an overload to the factories and run template argument deduction for > explicit arguments ([temp.deduct]/1-5). If the class template has not > suffered a deduction failure, terminate deduction and restart overload > resolution using its constructors. > > > > I=E2=80=99d also like to propose enforced copy elision, such that simple = factory > functions don=E2=80=99t require move construction. (Call it =E2=80=9Cperf= ect return.=E2=80=9D) This > seems like a separate feature. However, it would be nice to have both. > > > > Long ago, in some early C++ implementations at least, constructors *were*= non-member > factory functions. Hopefully this won=E2=80=99t be seen as =E2=80=9Ccomin= g full circle.=E2=80=9D > It=E2=80=99s really not, since the factory has no special abilities or st= atus > besides sharing a name. > > > > - D > > > --=20 ---=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. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --bcaec5489e45cbcbb305194c4a26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Jun 24, 2015 at 2:55 PM, Michael Spertus <mike_spertus@symant= ec.com> wrote:

Hi David,

That sounds to me essentially like the factory functions part of th= e proposal except you allow bodies in them. Is that correct? We explicitly = rejected that because I felt that the body belonged in the class and was co= nsistent with C++=E2=80=99 traditional values about what should be in the c= lass definition (Although I can=E2=80=99t speak for Richard=E2=80=99s motiv= ation, he also explicitly forbid defining the body).

=

I arrived at the current "guiding dec= larations" approach as a special case of a more general mechanism. Som= etimes you want a function template that has some non-trivial way of comput= ing its desired parameter types from the types of its arguments. This can&#= 39;t be done in today's C++: if you capture your argument types through= deduction, your parameter types must exactly match the argument types. So = the feature I was considering would allow this:

= =C2=A0 template<typename ...Args> void f_impl(maybe_add_ref<Args&g= t;...);
=C2=A0 template<typename ...Args> some_keyword_mayb= e f(Args...) -> f_impl<Args...>;

The seco= nd declaration is a deduction guide: it says, when you see a call f(blah), = and that function is the best viable function, then proceed as if f were re= placed by f_impl<Args...>. And for constructors:

=
=C2=A0 template<typename T> some_keyword_maybe vector(initialize= r_list<T>) -> vector<T>;

... says e= ssentially the same thing: when you see vector{1, 2, 3}, if that declaratio= n is the best viable function (say, with T =3D int), then 'vector' = really means 'vector<int>'.

One reas= on why you would want something like this instead of giving a definition to= the constructor (or function template) is to avoid duplication -- you alre= ady have the constructor definition, and shouldn't be repeating it in t= he way the old make_-function pattern forced you to. Another reason is to a= void unnecessary copies / moves of function arguments.
=C2=A0

=C2=A0A point in f= avor of your approach is that Bjarne=E2=80=99s unified function call syntax= proposal is to support =E2=80=9Cexternally defined methods=E2=80=9D but do= esn=E2=80=99t work for constructors.

=C2=A0

I plan to start looking at the next revision in about a m= onth. OK if we discuss then?

=C2=A0

Thanks,

=C2=A0

M= ike

= =C2=A0

From: David Krauss [mailto:potswa@gmail.com]
Sent: Wednesday, June 24, 2015 4:4= 5 AM
To: Michael Spertus; std-proposals@isocpp.org
Cc: Richard S= mith
Subject: Factory functions as deducing constructors? (N4471)=

=C2=A0

Hi Mike,=

=C2=A0

=

Most libraries already implement factory functi= on templates, e.g. make_thing().= Why not just let them be named e.g.=C2=A0thing(), aliasing the class template?

=C2=A0

  • No new deduction rules are needed.<= /li>
  • It=E2=80=99s a non-breaking change because such= aliasing is currently disallowed.
  • It differs from established practice only by renaming.
    • =
  • The full flexibility of factory functions is preser= ved, including explicit template arguments.
  • It does not intrude into the class template implementation.

=C2=A0

For the sake of member templates, such = a function template (or function) should still be found by a qualified-id p= receded by the typename keyword.= It should also be illegal to take its address, or to do anything with its = name or template-id besides call it. The factory should defer to real const= ructors when the explicit template argument list satisfies the class templa= te parameters.

= =C2=A0

Require the factory to b= e declared after the initial declaration of the class template, and require= its return type to be a specialization.

=C2=A0

= Implementation model: Attach the overload set of factory functions to the c= lass template. When name lookup finds the class template, grab the factorie= s too. If template arguments are provided, treat the class template as an o= verload to the factories and run template argument deduction for explicit a= rguments ([temp.deduct]/1-5). If the class template has not suffered a dedu= ction failure, terminate deduction and restart overload resolution using it= s constructors.

= =C2=A0

I=E2=80=99d also like to= propose enforced copy elision, such that simple factory functions don=E2= =80=99t require move construction. (Call it =E2=80=9Cperfect return.=E2=80= =9D) This seems like a separate feature. However, it would be nice to have = both.

=C2=A0

Long ago, in some early C++ impleme= ntations at least, constructors=C2=A0were=C2=A0non-member factory fu= nctions. Hopefully this won=E2=80=99t be seen as =E2=80=9Ccoming full circl= e.=E2=80=9D It=E2=80=99s really not, since the factory has no special abili= ties or status besides sharing a name.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - D

=C2=A0<= /u>


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--bcaec5489e45cbcbb305194c4a26-- .