220 41055 <8623f882-d191-4a10-b045-0e1823a38fab@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Balog Pal Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Primary constructors for C++ ? Date: Sat, 17 Nov 2018 15:31:59 -0800 (PST) Lines: 199 Approved: news@gmane.org Message-ID: <8623f882-d191-4a10-b045-0e1823a38fab@isocpp.org> References: <05c2d528-9837-4968-b19e-42875434962c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1728_289904313.1542497519257" X-Trace: blaine.gmane.org 1542497396 24571 195.159.176.226 (17 Nov 2018 23:29:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 17 Nov 2018 23:29:56 +0000 (UTC) Cc: ripopov@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDXOZDWV5QORB4GJYLPQKGQE7HBLU4Y@isocpp.org Sun Nov 18 00:29:52 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw1-f71.google.com ([209.85.161.71]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gOA2B-0006IC-MD for gclcip-std-proposals@m.gmane.org; Sun, 18 Nov 2018 00:29:51 +0100 Original-Received: by mail-yw1-f71.google.com with SMTP id k187-v6sf20129342ywe.7 for ; Sat, 17 Nov 2018 15:32:02 -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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=4p42ZHiA9XoBKYkpV04otwrrcTtWV66F25w79YUwx8M=; b=pTCD0x8bQFkXEVpfLyV1+d5Ocmvkkn74M0uFYIr+Zo+fJvpPZiygVaF1RbnBsQSMlx KwIwFt6x7POVIEInbNmzBxCwNHlZ2qTmSDxiHbMlghj0QNTXOiYi+OGieKcoNGD7nt8J f2G2ToeuFIq0i/PkXze8MGWIKXGnBTdGQ8RJzCYPatIx3F+1aevZ+74Jphv2FXnKQkng CyisCgJ97DkY61vU3lExPpMJnCvVZ4B3SmPZG2mA7rJ5XjXuqKOmQ6cuqXOpNOFnuElB HRzYSQAFfOPqeHmsvdQFzBpUWULzwOuSzKJn5ZSXSklEuFFbpUsJLedGZ+CEQk4jYInI Zm3A== 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=4p42ZHiA9XoBKYkpV04otwrrcTtWV66F25w79YUwx8M=; b=JbF8OD7kY/uE8lE4164l3mlWrIn9LEVvLHG9LHUhcssM4Da1paKCg7GpHaLkp88G6W fRY+LCVkekNEZxB1vwImk7Y+kBcRxLVjImlPqLNIejBT0MmYm4WvzeKILEsR5igQ64oZ OMS3gEuFQxeaK85W7/5cNXqCrQWwSMyh9M7xMm1QE3qe4UnwEn8VY/wQ7prbvdJb+iOt atnWYZIBof5iiipPy3UVQYuC49j+EsafINMmnjPKv3LAzUlOUfmgRaxCERRwuSfbmeXg BjW8Ssbe8xJkoT53ea894LJgx5QVcVhgVcnJ313Pu+/ZT1EAP/iP8R12UFaZYsYEPTb0 jSAw== X-Gm-Message-State: AGRZ1gJewkRQP2iJiyGBgq40TRU80rjv3dnm3DPSknXxY+hdKznV/s/K jamZNK2O1HX5wGNgYecA5+4L1A== X-Google-Smtp-Source: AJdET5fAboCaghzll07zjDg1Kx+ttEVdt8Tz4LL4M1EkbbA7fe5Z8h6XGw2oz15F6OpmzwstSRfxNw== X-Received: by 2002:a25:f816:: with SMTP id u22-v6mr4851661ybd.42.1542497521919; Sat, 17 Nov 2018 15:32:01 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:d915:: with SMTP id q21-v6ls10802090ybg.7.gmail; Sat, 17 Nov 2018 15:32:00 -0800 (PST) X-Received: by 2002:a25:f207:: with SMTP id i7-v6mr97853ybe.3.1542497520172; Sat, 17 Nov 2018 15:32:00 -0800 (PST) In-Reply-To: <05c2d528-9837-4968-b19e-42875434962c@isocpp.org> X-Original-Sender: pasa@lib.hu 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:41055 Archived-At: ------=_Part_1728_289904313.1542497519257 Content-Type: multipart/alternative; boundary="----=_Part_1729_1831666915.1542497519258" ------=_Part_1729_1831666915.1542497519258 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 2018. szeptember 25., kedd 19:21:27 UTC+2 id=C5=91pontban rip...@gmail.com = a=20 k=C3=B6vetkez=C5=91t =C3=ADrta: > > C++11 allows in-class member initialization. However, in-class=20 > initializers have no access to constructor parameters, which makes them= =20 > useless in many scenarios. > Yes, the by-member initializers are there for the ctors not providing a=20 different initializer. =20 > So essentially in this case C++ favors compile-time template interfaces= =20 > over run-time constructor interfaces > > ??? C++ favors nothing, it provides tools for the initialization that are=20 pretty clear and usable for all use cases. You can state the common/default= =20 value at the member, then make a series of ctors delegating to each other= =20 for more sophisticated init. =20 Or for simple cases you can even use the aggregate-init, to just dump=20 values instead of having the ctor that sets up a proper state. =20 > Currently we have to use old constructor member initializer list syntax,= =20 > if we need to pass parameters in run-time. This is less readable: member= =20 > initialization is separated from declaration. > As the means of setting up the state belongs to the implementation, it=20 looks fairly natural to me. Why should it appear at declaration? And how?= =20 And if your shop believes it must appear inside the class, what stops you= =20 to just order the ctors implemented inline? *Possible solution: * > > > Primary constructors (similar to Scala, Kotlin and abandoned C# proposal) > > > We can designate one constructor as primary. Parameters of primary=20 > constructor should be visible to in-class initializers. All other=20 > constructors must call primary constructor in their constructor=20 > initialization list. Primary constructor is public by default. > This certainly CAN be done, but question remains whether the related=20 trouble in specification, implementation and code rearranging is worth the= =20 result. You need to show up some evidence beyond that it is more appealing= =20 to your aestetics. =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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/8623f882-d191-4a10-b045-0e1823a38fab%40isocpp.or= g. ------=_Part_1729_1831666915.1542497519258 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2018. szeptember 25., kedd 19:21:27 UTC+2 id=C5=91= pontban rip...@gmail.com a k=C3=B6vetkez=C5=91t =C3=ADrta:

C++11 allows in-class member initialization. However, in-class init= ializers have no access to constructor parameters, which makes them useless= in many scenarios.


Yes, the by-member initializers are there for the ctors not providing a di= fferent initializer.
=C2=A0

So essentially in this case C++ favors compile-time templ= ate interfaces over run-time constructor interfaces


<= /blockquote>
???
C++ favors nothing, it provides tools for th= e initialization that are pretty clear and usable for all use cases. You ca= n state the common/default value at the member, then make a series of ctors= delegating to each other for more sophisticated init.=C2=A0

Or for simple cases you can even use the aggregate-init, to= just dump values instead of having the ctor that sets up a proper state.
=C2=A0

Cur= rently we have to use old constructor member initializer list syntax, if we= need to pass parameters in run-time. This is less readable: member initial= ization is separated from declaration.


As the means of setti= ng up the state belongs to the implementation, it looks fairly natural to m= e. Why should it appear at declaration? And how? And if your shop believes = it must appear inside the class, what stops you to just order the ctors imp= lemented inline?

Possible solution: =C2=A0


Primary= constructors (similar to Scala, Kotlin and abandoned C# proposal)

<= br>

We can designate = one constructor as primary. Parameters of primary constructor should be vis= ible to in-class initializers. All other constructors must call primary con= structor in their constructor initialization list. Primary constructor is p= ublic by default.

<= /div>

This certainly CAN be done, but quest= ion remains whether the related trouble in specification, implementation an= d code rearranging is worth the result. You need to show up some evidence b= eyond that it is more appealing to your aestetics.=C2=A0=C2=A0


--
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/8623f882-d191-4a10-b045-0e1823a38fab= %40isocpp.org.
------=_Part_1729_1831666915.1542497519258-- ------=_Part_1728_289904313.1542497519257-- .