220 30527 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Named constructors Date: Thu, 12 Jan 2017 11:44:12 -0500 Lines: 209 Approved: news@gmane.org Message-ID: References: <84cb007b-d3c2-4204-be97-27f7f0df0e7d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113dcb065454ab0545e86d87 X-Trace: blaine.gmane.org 1484239459 2391 195.159.176.226 (12 Jan 2017 16:44:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jan 2017 16:44:19 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBXPE33BQKGQEHDU6D6I@isocpp.org Thu Jan 12 17:44:14 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRiTx-00088Q-NB for gclcip-std-proposals@m.gmane.org; Thu, 12 Jan 2017 17:44:10 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id d13sf44558539oib.3 for ; Thu, 12 Jan 2017 08:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :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=MwpfvjheCHwftGBt7A4aj+HJM8nxoV6egbUNZ+Bcrio=; b=Bfusx9yrza5zd4PKYMgZuCmvKlt5LS82N+HXBuQEaCYyCCGjl51BqExH1mINBehgZY tXOoSvmK4OZfV3/im6I/h6gd6lKb2zLrXUtg/9hk902gTaKHTKoTQsvbQjZjfssxEP6z iwG/NO+XaIk8mvvppAOruXa7MB92O+3LF3l+oiLswOT7byQJ4Q7144sIhTckNi3uE6Tv w0NTN+JaYUcJhFP4dsyHdKbOoldQD3ohA4qZlm60zIM7uZFoz5WUfmhlQ78qISDtvB9y /nAmIiIFvxcOCmBF8g6HKPD80oCmItWxc9XkfRIkbeVmTJ4dlcrGotrwWLgDM8rJk0n/ AgIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to: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=MwpfvjheCHwftGBt7A4aj+HJM8nxoV6egbUNZ+Bcrio=; b=AX+HnPUvSSiH3IKyPD2xl6pTXIeFUX2GskWAqlXzYa8yuLtly32WWqkKFbg8QenkFC lMdCyNoWOyveWoVu+lGtBbRaLRVaRIbTWlRv8f/gEOKIHZ33KZFrDMWpy3wOAz1tkECw jLcKvWQ9u0qDw24QB1tu96by/PYMAW0Y26dRDPuLvZB4GZN/cpX53MPOQocVxXFB34Tj rxhtbZH8k1/aCbOjXbWIzq6jjKK2rOGuMyyXU9SpaGkHeWd9789WQwhC7vFXr9CcXp0j QVXIkgpm3c4SrKQvMPMcLvgMUvs7QV3lQ0wNC+u0EOYyKp5g+I3CQc8NvekVrnFPoR70 75jA== X-Gm-Message-State: AIkVDXIQN6QBYUDWaI5luzx56I36PO6WxR6tCbDHBcHeDfonAaI2oYOmQ/CQ3piPXVdflg== X-Received: by 10.157.22.232 with SMTP id s37mr4776266ots.63.1484239454115; Thu, 12 Jan 2017 08:44:14 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.59.34 with SMTP id z31ls6866993otb.21.gmail; Thu, 12 Jan 2017 08:44:13 -0800 (PST) X-Received: by 10.157.15.103 with SMTP id 94mr7121564ott.104.1484239453038; Thu, 12 Jan 2017 08:44:13 -0800 (PST) Original-Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com. [2607:f8b0:4003:c06::22d]) by mx.google.com with ESMTPS id t56si3873090otd.139.2017.01.12.08.44.13 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jan 2017 08:44:13 -0800 (PST) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c06::22d as permitted sender) client-ip=2607:f8b0:4003:c06::22d; Original-Received: by mail-oi0-x22d.google.com with SMTP id j15so29276983oih.2 for ; Thu, 12 Jan 2017 08:44:13 -0800 (PST) X-Received: by 10.157.29.143 with SMTP id y15mr7693714otd.214.1484239452505; Thu, 12 Jan 2017 08:44:12 -0800 (PST) Original-Received: by 10.74.90.193 with HTTP; Thu, 12 Jan 2017 08:44:12 -0800 (PST) In-Reply-To: X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@google.com; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c06::22d as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Original-From: Matt Calabrese 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:30527 Archived-At: --001a113dcb065454ab0545e86d87 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 11:02 AM, Nicol Bolas wrote: > On Thursday, January 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote: >> >> On Thu, Jan 12, 2017 at 8:07 AM, wrote: >> >>> I find my self regularly creating static factory functions on classes to >>> better describe how something is being constructed or to avoid having flags >>> passed which may have some invalid permutations. Now some times this is >>> because of poor design(Lazy/efficient) but it does make me wonder if >>> constructers with names different to their class would be helpful. >>> >> >> I agree that the language needs named constructors, though this obviously >> needs a paper and the syntax probably has to undergo bikeshedding. The >> standard library keeps adding constructor tags to effectively get names, >> and we often have to make wacky SFINAE hacks to make those constructor >> overloads play nicely with other overloads. Named constructors more >> directly solve the problem (in contrast to tag types) and also makes >> overload sets smaller, making the code easier to reason about and to >> specify correctly (indirectly, it might even slightly improve compile times >> as well, but this is less of a concern). Guaranteed copy elision gets us >> close to having an equivalent of named constructors because it allows for >> named factory functions that return by value yet don't need the type to >> even be movable. That only solves some of the issues, though, and in >> practice, it still sometimes requires having (likely private) tagged >> constructor overloads. Named constructors might also be able to have a >> beneficial relationship with C++17 deduction guides. >> >> I'd really like for someone to flesh out named constructors more in a >> paper and come back with something more tangible/formal, covering all of >> the details. >> > > One problem I have with named constructors (as opposed to just static > functions that return `T`) is that it doesn't solve the problem. The whole > point of named constructors is that you have to provide a name to call the > right function, yes? > > Well, `T(...)` doesn't provide that name, so it can only call regular > constructors. > The reason I want the idea fleshed out is because there ideally would be syntax for the name there. > List-initialization can only call regular constructors, since it also has > no name, just a type and parameters. Indirect initialization (`emplace`, > `in_place_t` constructors, `make/allocate_shared/unique`, etc) can only > call regular constructors for the same reason. > If the change were made without considering library, then I agree, but I don't think that's a roadblock. The addition of named constructors would likely have implications on how we design new/update existing library facilities and there's no reason to believe that we couldn't adjust appropriately. Here's one example of what I mean -- previously in these forums I've described that it would have been nice to have had something more akin to a conceptified version of boost's in_place facilities rather than or in addition to what we do today for emplacement. One of the reasons I say this is because if done correctly, users could, for example, perform emplacement via the result of a function call. The benefit of this particular approach, especially with respect to *guaranteed* copy/move elision of C++17, is that it allows for zero copies/moves even if you are constructing via a named function with no directly corresponding constructor. Short of that kind of abstraction, you could certainly imagine an "emplace_with_result" that takes an Invocable and a set of arguments, where it constructs in-place with the result of the function call. With that kind of facility, also consider the possibility of being able to take the address of a named constructor (why not? think of the constructor sort of like static function that returns the constructed object). Then, all you'd have to do is pass that in as the Invocable, followed by your desired arguments. Now you can emplace with a named constructor. Regarding named constructors that are *overloaded* or are templates, there are already proposals to allow easily converting a set of overloads into a lambda that does the dispatching (and it's a less controversial proposal for the closed-set of overloads of class members). If we get something like that, then this solution even works concisely when you have such a templated or overloaded named constructor. With such an "emplace_with_result" kind of function, the benefits of named constructors over a named function that simply returns T are the ability to directly initialize bases and members. Without the ability to do that, your named function needs to use some existing constructor (maybe private, and likely still requiring the tag/SFINAE dance behind the scenes). My point is, these are all solvable problems, they just have broader implications if. It could end up being that these aren't changes that we end up wanting to do, but without a paper that really formally explores the options, it's hard to say. -- 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/CANh8DEm0yZnZ4zf1mp4Pn_c%3DpkgJ%3DW71Nz3Kugd8th3wVcUzsg%40mail.gmail.com. --001a113dcb065454ab0545e86d87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jan 12, 2017 at 11:02 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
On Thursday= , January 12, 2017 at 10:39:12 AM UTC-5, Matt Calabrese wrote:
On Thu, Jan 12, 2017 at 8:07 AM, <= ;stefan...@torstonetech.com> wrote:
I find my = self regularly creating static factory functions on classes to better descr= ibe how something is being constructed or to avoid having flags passed whic= h may have some invalid permutations. Now some times this is because of poo= r design(Lazy/efficient) but it does make me wonder if constructers with na= mes different to their class would be helpful.

<= /div>
I agree that the language needs named constructors, though this o= bviously needs a paper and the syntax probably has to undergo bikeshedding.= The standard library keeps adding constructor tags to effectively get name= s, and we often have to make wacky SFINAE hacks to make those constructor o= verloads play nicely with other overloads. Named constructors more directly= solve the problem (in contrast to tag types) and also makes overload sets = smaller, making the code easier to reason about and to specify correctly (i= ndirectly, it might even slightly improve compile times as well, but this i= s less of a concern). Guaranteed copy elision gets us close to having an eq= uivalent of named constructors because it allows for named factory function= s that return by value yet don't need the type to even be movable. That= only solves some of the issues, though, and in practice, it still sometime= s requires having (likely private) tagged constructor overloads. Named cons= tructors might also be able to have a beneficial relationship with C++17 de= duction guides.

I'd really like for someone to= flesh out named constructors more in a paper and come back with something = more tangible/formal, covering all of the details.
<= /blockquote>

One problem I have with named constructors (as = opposed to just static=20 functions that return `T`) is that it doesn't solve the problem. The wh= ole point of named constructors is that you have to provide a name to call = the right function, yes?

Well, `T(...)` doesn't provide that nam= e, so it can only call regular constructors.
<= br>
The reason I want the idea fleshed out is because there ideal= ly would be syntax for the name there.
=C2=A0
List-initialization can only call r= egular constructors, since it also has no name, just a type and parameters.= Indirect initialization (`emplace`, `in_place_t` constructors, `make/alloc= ate_shared/unique`, etc) can only call regular constructors for the same re= ason.

If the change were ma= de without considering library, then I agree, but I don't think that= 9;s a roadblock. The addition of named constructors would likely have impli= cations on how we design new/update existing library facilities and there&#= 39;s no reason to believe that we couldn't adjust appropriately.
<= div>
Here's one example of what I mean -- previously in t= hese forums I've described that it would have been nice to have had som= ething more akin to a conceptified version of boost's in_place faciliti= es rather than or in addition to what we do today for emplacement. One of t= he reasons I say this is because if done correctly, users could, for exampl= e, perform emplacement via the result of a function call. The benefit of th= is particular approach, especially with respect to *guaranteed* copy/move e= lision of C++17, is that it allows for zero copies/moves even if you are co= nstructing via a named function with no directly corresponding constructor.= Short of that kind of abstraction, you could certainly imagine an "em= place_with_result" that takes an Invocable and a set of arguments, whe= re it constructs in-place with the result of the function call. With that k= ind of facility, also consider the possibility of being able to take the ad= dress of a named constructor (why not? think of the constructor sort of lik= e static function that returns the constructed object). Then, all you'd= have to do is pass that in as the Invocable, followed by your desired argu= ments. Now you can emplace with a named constructor. Regarding named constr= uctors that are *overloaded* or are templates, there are already proposals = to allow easily converting a set of overloads into a lambda that does the d= ispatching (and it's a less controversial proposal for the closed-set o= f overloads of class members). If we get something like that, then this sol= ution even works concisely when you have such a templated or overloaded nam= ed constructor.

With such an "emplace_with_re= sult" kind of function, the benefits of named constructors over a name= d function that simply returns T are the ability to directly initialize bas= es and members. Without the ability to do that, your named function needs t= o use some existing constructor (maybe private, and likely still requiring = the tag/SFINAE dance behind the scenes).

My point = is, these are all solvable problems, they just have broader implications if= .. It could end up being that these aren't changes that we end up wantin= g to do, but without a paper that really formally explores the options, it&= #39;s hard to say.

--
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/CANh8DEm0yZnZ= 4zf1mp4Pn_c%3DpkgJ%3DW71Nz3Kugd8th3wVcUzsg%40mail.gmail.com.
--001a113dcb065454ab0545e86d87-- .