220 30528 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Named constructors Date: Thu, 12 Jan 2017 09:05:31 -0800 (PST) Lines: 323 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/mixed; boundary="----=_Part_834_1810648518.1484240731356" X-Trace: blaine.gmane.org 1484240744 6403 195.159.176.226 (12 Jan 2017 17:05:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 12 Jan 2017 17:05:44 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBXHO33BQKGQEOYJPDHY@isocpp.org Thu Jan 12 18:05:39 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cRiof-0000DW-G3 for gclcip-std-proposals@m.gmane.org; Thu, 12 Jan 2017 18:05:33 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id r136sf13728560vke.6 for ; Thu, 12 Jan 2017 09:05:33 -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=2vN7qu/y/RIZSyeCAqhrpVVOWLZJh9iaikSpcy4QUWE=; b=oO6t7T3c1r45H1Wdl+qe6bb8z+EdWYEmCBpN4E2tnsuSrBgVhzayq+R0lz3wTkGAEY OfFpGzMA31nSlp3mwXI8yivH1sqpbmGNHJaywpNWz+p1I7VgK5s9OaxlZylRGPv9Fgck jxJM44IEVHJKjX1KDexaeJc3c25jjPrWh6E28zQOuWYMtes6KhYjRWkBCqAMlqvEfBx6 LmMQmzYjbdxes3L6Grj11X6f0TgQUqBikRRPqIzZH9ND0MLN9O8rAJpquDfchZZfAGJ5 c/UYOx4PT5Ra26cWbf4Y7h8IZY59HO68xDEMn/5zXW18w0C62wuqm0E1zmFUfX6zUqZX dz2w== 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=2vN7qu/y/RIZSyeCAqhrpVVOWLZJh9iaikSpcy4QUWE=; b=CctcvWmC3ROHi422uGbQh70lS/oGxx5kneMgpLlRPf0+tAdiVyfP+UBLLs2qFiy2el ZkxK5wVGASNhRiXmE7k2Izey2MQzZa3IXzpAbqA4jwXpCHukOusu7YIft2yCrqpzbuFb AExbl0Pl6k7hiqQcMbXwsAZNSKBHvcrQYMXQaexdIOnhNhtOxo93lJ+7bvmgiofuFq9U VTjnpMtn4MHtlogHlhoghHvNtpKNZc+d7MNpwVYnNw6n9HiGA4/YDNy1BVdeKSb8y9av 8gGa8wO+uT0QNUregmBjIPOjaWx325rnuQGkb/xMCxK41ZHxM7oI4rLLZ1u4UQ1697lP 2ZgQ== 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=2vN7qu/y/RIZSyeCAqhrpVVOWLZJh9iaikSpcy4QUWE=; b=RY3pTEi21c6n+a+LQcc0usvkBhd0VNsCuhEdcvpScEBd04CtmJtTDhtpuVQjMS0S7Q ielH0Cdh/wl6qwU8L0lZYXC4H6RXVNCSVCuRUQoqMUFk2qLf4G1uHCJl4RWuynno5Uod +kraZ3yfd10p5AEA79HF1iUiuOc7jgcQz6yI7fSwi09yeTg/eig12ayffMOxPMUhGPox fp2RwFp5Y+K6cilNHhfiSxHiR0dmIEJ6wMIV+hicisLDZYYT5W5jihcQOESFB74ei0bm rsgBYOSY3LFuzVzN2lWi+3Asnc8r6rG/gI1EZEJneoSTj0oCCmCeRbYF8joswHE/j7AY QV5A== X-Gm-Message-State: AIkVDXJ0vay7qqATgpnu+WQ3uhw+RsPCyIQE+OSaPx25LFa4BIeSNy6/+pKsIUpAF7uD0g== X-Received: by 10.176.84.154 with SMTP id p26mr4339262uaa.40.1484240732814; Thu, 12 Jan 2017 09:05:32 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.9.140 with SMTP id q12ls7038476otd.6.gmail; Thu, 12 Jan 2017 09:05:31 -0800 (PST) X-Received: by 10.157.4.105 with SMTP id 96mr196463otc.17.1484240731920; Thu, 12 Jan 2017 09:05:31 -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:30528 Archived-At: ------=_Part_834_1810648518.1484240731356 Content-Type: multipart/alternative; boundary="----=_Part_835_1513807751.1484240731357" ------=_Part_835_1513807751.1484240731357 Content-Type: text/plain; charset=UTF-8 On Thursday, January 12, 2017 at 11:44:14 AM UTC-5, Matt Calabrese wrote: > > 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. > So let's say we go through this effort. We add a lot of functions to the standard library. We add yet another language feature: lifting lambdas (which I'm all in favor of, regardless of this stuff). And probably some lip-service to list-initialization. Whatever. And after all of that work, we get... the ability to do this: auto t = Temperature::FromKelvin(...); rather than this: auto t = Temperature::FromKelvin(...); Or the ability to do this: v.emplace_back_with_result([]Temperature::FromKelvin, ...); Rather than this: v.emplace_back(..., Temperature::FromKelvin); I'm really trying to understand how the named constructor version is an improvement, but it's just not coming to me. From the perspective of the person calling the code, named constructors don't seem to be an improvement over static members and tags. You keep talking about "the tag/SFINAE dance" as though it were some complex and nightmarish code. But in most cases I've seen, it's pretty simple stuff. The result on the user end side is quite readable. I wouldn't even bother with a type for the case of `Temperature`; an enum is perfectly acceptable. And whatever SFINAE gymnastics you have to do will become much more reasonable once we get concepts, right? -- 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/fb643c63-11ee-4d15-a577-1321362ceb99%40isocpp.org. ------=_Part_835_1513807751.1484240731357 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thursday, January 12, 2017 at 11:44:14 AM UTC-5= , Matt Calabrese wrote:
On Thu, Jan 12, 2017 at 11:02 AM,= Nicol Bolas <jmck...@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 describe how something is being cons= tructed or to avoid having flags passed which may have some invalid permuta= tions. 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 wo= uld be helpful.

I agree that the lang= uage needs named constructors, though this obviously needs a paper and the = syntax probably has to undergo bikeshedding. The standard library keeps add= ing constructor tags to effectively get names, and we often have to make wa= cky 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 slight= ly improve compile times as well, but this is less of a concern). Guarantee= d 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&= #39;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 priva= te) tagged constructor overloads. Named constructors might also be able to = have a beneficial relationship with C++17 deduction guides.

<= /div>
I'd really like for someone to flesh out named constructors m= ore 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=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.

So let'= s say we go through this effort. We add a lot of functions to the standard = library. We add yet another language feature: lifting lambdas (which I'= m all in favor of, regardless of this stuff). And probably some lip-service= to list-initialization. Whatever.

And after all of that work, we ge= t... the ability to do this:

auto t =3D Temperature::FromKe= lvin(...);=

rather than this:

auto t =3D Temperature::FromKelvin(...);

Or the ability to do this:
v<= /span>.emplace_back_with_re= sult([]Temperature::FromKelvin, ...);

Rather t= han this:

v= ..emplace_b= ack(..., Temperature::FromKelvin);
=
I'm really trying to understand how the named constructor version i= s an improvement, but it's just not coming to me. From the perspective = of the person calling the code, named constructors don't seem to be an = improvement over static members and tags.

You keep talking about &qu= ot;the tag/SFINAE dance" as though it were some complex and nightmaris= h code. But in most cases I've seen, it's pretty simple stuff. The = result on the user end side is quite readable. I wouldn't even bother w= ith a type for the case of `Temperature`; an enum is perfectly acceptable.<= br>
And whatever SFINAE gymnastics you have to do will become much more = reasonable once we get concepts, right?

--
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/fb643c63-11ee-4d15-a577-1321362ceb99= %40isocpp.org.
------=_Part_835_1513807751.1484240731357-- ------=_Part_834_1810648518.1484240731356-- .