220 38165 article Path: news.gmane.org!.POSTED!not-for-mail From: Viacheslav Usov Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Better DRY when initializing members in constructor Date: Thu, 24 May 2018 12:28:43 +0200 Lines: 101 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a3bcc1056cf11df4" X-Trace: blaine.gmane.org 1527157600 14515 195.159.176.226 (24 May 2018 10:26:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 24 May 2018 10:26:40 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBDU6VRPKW4BBBXFHTLMAKGQEV4MEBAQ@isocpp.org Thu May 24 12:26:35 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fLnS6-0003g1-Or for gclcip-std-proposals@m.gmane.org; Thu, 24 May 2018 12:26:34 +0200 Original-Received: by mail-pf0-f197.google.com with SMTP id d20-v6sf728217pfn.16 for ; Thu, 24 May 2018 03:28:46 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1527157725; cv=pass; d=google.com; s=arc-20160816; b=CMU/Tkvd3ZU42bgXDN6Kl5b3zVl6SR40DthEmuYORiPewBt5aSMJveEceNHU/KjdP+ HY/X/p1WWCRLwhd/LNVRh4/SOOF3bnlYNnWssPlQf8nvsgXa+2rRpAhsJp7fZv0rKA6m XM2NrB+ACicSg7+KMmI7xtBLMFaS7REXCQD20X49cdg82xrCxrMCnF0nEGWWM8wAR6tO /C5Qpcms6zQgOP0yvCQbGlqtw5Otea6on8Zbbzw5SSpAt0C31bLNgYTXIy8bFgJFh0EH ZnyQDc8OOIk8nJnRZNEPMDZpcDCJA5wzWsnAumMF7tflqlBR2fPCi8XaS0+gatk5v9bR Uoww== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=83VTn+LQ3IJJu9tWMFWmGllXt2TAbOAneMK3EeGQRsE=; b=MF17lr4wClPqYk7wGrLXjRsBNGEBZ6yWHNvF9ll7dKix1RAFDERulpDWfZorz0tMKY BMjdcwkyC8PVUkyUsu8GC3hZ9xzaPIuGFRBqV/y8ZoTktbQ7wrh0E57D9/XANYjS8nJG HxqJeNXEXA2Gi084clsf40Jiiaegg2gUPJuxntJlClzw917GyLyecHyiyZ6toI0dAYAG msHrhj+0G2dchDEZk39h+k2oj/g1PstWkqb9nV8csaHwpf38VVEauB+V58VANyC5jsbu vlAWlxr7ZrwpwH7CVTIbJ7sLORbLhdHi+GjP9h/8lj1AkhSlJxTjqPuiLmtBP5AHBjfy 5Zpw== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kRPn4MXd; spf=pass (google.com: domain of via.usov@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=via.usov@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com 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:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=83VTn+LQ3IJJu9tWMFWmGllXt2TAbOAneMK3EeGQRsE=; b=JCiJH9xxVnYAPtjvoSwjWFOGCX55DLvqhf6mMWDgscs51xoqo01U18PyvlFJjEsa8W 1A6D9fsrImJLRp2kxbjAtGqa0bkRyPjbPrnHRDr7YouxC/XBMIdXIFKSdACxmKBBC6yv rv311fDMMBqP+Eci8fAEfYVZFlR3n4EIGtbrs4CqN2yU4MwNkKdGRL7HAbH5sWsvnf9X UEwsSlzWA8NW6ADUvUNm9yVmRiE/v/7aQLbLx6IBqu/WkUvHXjRyNkAa2jDQ0axzj0/0 UyfSWm8T51qlJ5qtxEYiv1IVwVCCqO7EjCyUhQe30/HshOKdZa9L0hj4C2Ssba8xZ2F7 OoxA== 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=83VTn+LQ3IJJu9tWMFWmGllXt2TAbOAneMK3EeGQRsE=; b=M6h+OWGXXX8k9+5WK5AmtXXMGJk15Q0+hvY/wcwWy8m+2zMOUAYGUMLZvfPsX9LKID tBN3DTZwsnBwdZfQBBOC84MZODvTNo4n87qYizjPKOIiRAjbWyW2uJk7hbp86xFZiwno SSWpIbvvaor9NH2H04/Dx1AoCaa/QyjngM5H3qDPVdoOtVtozUs2F9AxxDlJ2PPPSTFg TXHuXE6k+kWLOf9G2Togb3jMfGYduAeoykr9U5MMJJsaK+S9Z9Q13LRYS7E335PuGXuT SuN91sEXwXEplByWCx6HjkxTWUWoDpjd/JZeGcsbw28K44DG2kwMBhR4Uq07WIp4PhvH BEcQ== X-Gm-Message-State: ALKqPwfPhNZTFZz/fhr9sG57nPu2Z6KPAh3GC57O0q9VAAsbw5zorMKj VTq1AiVRya9SiFiIaJ9FUXHDzA== X-Google-Smtp-Source: AB8JxZo/dxbttVgZQAlgTsvO2E3K9bDeKgSYqeRNbKZ2fXU0nprSCRK41vSmuTc5sXNVUrREuvn0ug== X-Received: by 2002:a17:902:9a94:: with SMTP id w20-v6mr1508311plp.18.1527157725612; Thu, 24 May 2018 03:28:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a65:6052:: with SMTP id b18-v6ls2365732pgv.9.gmail; Thu, 24 May 2018 03:28:44 -0700 (PDT) X-Received: by 2002:aa7:850f:: with SMTP id v15-v6mr6667474pfn.144.1527157724322; Thu, 24 May 2018 03:28:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527157724; cv=none; d=google.com; s=arc-20160816; b=IfbrU33U/RT90Hqa08KsAccPSvu0Qq1Q4/0fTGMLa7+XC38buL9UNsOwRUm7TSFolg O2XdHBg35HoHWE/NJOrC2ZJUtmYD/RptspMh+T7lQpCBBsnvZYQAS79y9whm3QBP8EyB yKyu8cBi4t22y137HYVeecqn5KD2iaHrU9OFC+nksee7GkzLtDN5D8jSA6ifMX7AB0gC BZye/2aiHFE5zmrH2fKpwqE4hHSTyUUnZ/1IvNUvfk62cQbEWsSaLzRqz3Z5Bzot9Hcb B6ltj4tTPwGxPZDQaQRrHQRIjp3Z5mIHEj7eoZA83fIlv1TPLtURviX7cLUzkdy13HdQ Qohg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=mI2N5ruuc4lwS6FZxAFtyW/gVL9MOnkixr6CPT30I/4=; b=IlyHDbG2uYtIl8Q8CzaFf+Lxi4CST5Fru8fdtVRAu4MhrNhCiGbpyplSKw/+spVGjU mtj1BN6/NyZkgqae24Po4caC6/coHZ7XUZ/TqUriCxZ1GMK3QogMUmTE0V5LYmq7ocUX L+3uXUV1A593K1aMwjZaBv9tzeZfv9/dmD1fmzQfvlhBZZvGVOEndFnzsMonjEWYVPxH I1aSVjn1UbgTBAM6YduKaBoiK21vZOAQkNkFg8bJMTJVeWxvWKSiO4ELr3H75rEOecM/ C0oIQMIavO+UUMMQ9nbwmmLZFu5nByHVmGdncHYDCusYJMJCw0XYtbEojYRqIHMdkbVF dwKw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kRPn4MXd; spf=pass (google.com: domain of via.usov@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=via.usov@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id 61-v6sor8257131plc.126.2018.05.24.03.28.44 for (Google Transport Security); Thu, 24 May 2018 03:28:44 -0700 (PDT) Received-SPF: pass (google.com: domain of via.usov@gmail.com designates 209.85.220.65 as permitted sender) client-ip=209.85.220.65; X-Received: by 2002:a17:902:1025:: with SMTP id b34-v6mr6632967pla.207.1527157723740; Thu, 24 May 2018 03:28:43 -0700 (PDT) Original-Received: by 2002:a17:90a:8d01:0:0:0:0 with HTTP; Thu, 24 May 2018 03:28:43 -0700 (PDT) In-Reply-To: X-Original-Sender: via.usov@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=kRPn4MXd; spf=pass (google.com: domain of via.usov@gmail.com designates 209.85.220.65 as permitted sender) smtp.mailfrom=via.usov@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=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:38165 Archived-At: --000000000000a3bcc1056cf11df4 Content-Type: text/plain; charset="UTF-8" On Mon, May 21, 2018 at 7:53 AM, Raymund Hofmann wrote: > Are there already some proposals/ideas for improving DRY on this? The entire issue arises when some members have to be initialised in a pass-through fashion, while the others in some other way. In the most general case, you might have different constructors with different sets of the pass-through parameters, and you cannot choose a preferred constructor. In this most general case, an obvious idea is that you say right in the constructor's parameter list that "this one is passed through", e.g.: S::S( =i, =cp ) {} This entire syntax is just an illustration.. The most general approach repeats the name of the pass-through member for each such constructor; it also repeats the name of the class once per constructor. Frankly, repeating the class name is ugly and has always been even irrespective of this entire issue, so we might consider an abbreviation for that (and destructors, for good measure). For example, the constructor can be abbreviated to :=(parameter list): init list {body} and the destructor to [virtual] :~() {body} (again purely an illustration, but := and :~ unlike some other candidates would make it easy to grep for these special members). So now we are down to one pass-through member repetition per constructor. I do not think it is possible to do better than this unless the problem is constrained further. struct S { int a; const char *b"; :=(=a) : b("123") {} :=(=b) : a(1) {} }; S(2), S("456"); Cheers, V. -- 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/CAA7YVg0akQ%2BZNcknomtdMGLrjYvaA_dkkL-9W_X9KtGy1Dxw%3DQ%40mail.gmail.com. --000000000000a3bcc1056cf11df4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, May 21, 2018 at 7:53 AM, Raymund Hofmann <hofmannraymund@gmail= ..com> wrote:

> Are there already so= me proposals/ideas for improving DRY on this?

The = entire issue arises when some members have to be initialised in a pass-thro= ugh fashion, while the others in some other way. In the most general case, = you might have different constructors with different sets of the pass-throu= gh parameters, and you cannot choose a preferred constructor. In this most = general case, an obvious idea is that you say right in the constructor'= s parameter list that "this one is passed through", e.g.: S::S( = =3Di, =3Dcp ) {} This entire syntax is just an illustration..
The most general approach repeats the name of the pass-through = member for each such constructor; it also repeats the name of the class onc= e per constructor. Frankly, repeating the class name is ugly and has always= been even irrespective of this entire issue, so we might consider an abbre= viation for that (and destructors, for good measure). For example, the cons= tructor can be abbreviated to :=3D(parameter list): init list {body} and th= e destructor to [virtual] :~() {body} (again purely an illustration, but := =3D and :~ unlike some other candidates would make it easy to grep for thes= e special members).

So now we are down to one pass= -through member repetition per constructor. I do not think it is possible t= o do better than this unless the problem is constrained further.
=
struct S
{
=C2=A0 =C2=A0 int a;
=C2=A0 =C2=A0 const char *b";

=C2=A0 =C2=A0= :=3D(=3Da) : b("123") {}
=C2=A0 =C2=A0 :=3D(=3Db) : a(= 1) {}
};

S(2), S("456");
=

Cheers,
V.

--
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/CAA7YVg0akQ%2= BZNcknomtdMGLrjYvaA_dkkL-9W_X9KtGy1Dxw%3DQ%40mail.gmail.com.
--000000000000a3bcc1056cf11df4-- .