220 40220 article Path: news.gmane.org!.POSTED!not-for-mail From: Jake Arkinstall Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Primary constructors for C++ ? Date: Tue, 25 Sep 2018 18:37:12 +0100 Lines: 95 Approved: news@gmane.org Message-ID: 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/alternative; boundary="000000000000bf83260576b58e3a" X-Trace: blaine.gmane.org 1537896916 24045 195.159.176.226 (25 Sep 2018 17:35:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2018 17:35:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDCZX3WUUQFRBUHEVHOQKGQE3GU6PSQ@isocpp.org Tue Sep 25 19:35:11 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it1-f200.google.com ([209.85.166.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4rEt-00066i-DJ for gclcip-std-proposals@m.gmane.org; Tue, 25 Sep 2018 19:35:11 +0200 Original-Received: by mail-it1-f200.google.com with SMTP id m207-v6sf8781400itg.5 for ; Tue, 25 Sep 2018 10:37:22 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1537897041; cv=pass; d=google.com; s=arc-20160816; b=eRj9AkmZVntld20QgWHp+DQSTtcqMfLqGhxarrJbTNFqBTuxWn6gZqCHs04jWHwnMf +lDBHhJRorZns1jyoER94tlKsH92N1n2LGPhX1rxfiS5vseceLgK8k4bqbg/MQRWGPar c7l2vMi/bne5WtsJ/hYPG2gEfMazJvlXhZekGhF69CZKgEC2MCkLfOHHL8ZCPHr9x42y m14kZUR1jUrtM5Aq1hCRADjFa9FR18G+58T11SJvYLTQbCwyGoT2dY/x3TvkkVeWoYbf YRc6wrb0J4iiN/KcN2HgMiluyqC+2MKDYckbLvO204gKpM/m6CT442xvGWAgh+m38wwp LVnQ== 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:in-reply-to:references:mime-version:dkim-signature; bh=lL0n728vUIdv161lehfhD3AFeb1S9gcTk2CiLDH/WpA=; b=cFaYFBF/eBXY/mEIG4jb6zh06ftB6TeWwKF0g68EESXI4SgsjM9GZdjoUz7fWQGYKK 8o99YDUgZoXpc9kMwV0brFq7UA9NdnnNZloD55mEJnovtylI+60TPO9Cs5upTuweCLR2 dafMaShgLlpzBmxE8XnHogELXJBCvmrukNH33qpaT1lolHtlw2S1o4FftMCa18MIkA8K GjFO7VD7fRSvX8mWUUfii4oVGB/nF+ce5buYEla6pxDJ4jztJO/JhlCAwaQbRqxFsF1v O3MBe3/Yk7yvhimpLfWlzsFq0xvleyFxE6XIThXIM0CyZ1W46uQWtjaipp8cGreF6V9f Pf0g== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UY0PI2ku; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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:references:in-reply-to: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=lL0n728vUIdv161lehfhD3AFeb1S9gcTk2CiLDH/WpA=; b=B8c/yF+AM11HNTkf3TW3EnOqTDqncZHxxoMZ/d/hHelMlJLiFhmUmy8dJAhpFzcMou bVlkTVt1rBIY9dnj064o64xUSx55xWPJLaotUDNS1yTor8lwLt0pJHvUtPhhmkgHUmHl tJxxYHBgzkwrrGAvP2ndDauyXM9+WhWOGN2gpzDjRPiZabRmcVg1gciDPpHqt0ScsGcO Tw/fQXXYWWUkOpnJR6mwK92CEysb43L5H4E4QQPmCXva+LELUp/ntp7oPhEh15VxW/JP WwdgO16tM1A9djmcQiLai/bhuoNpomhUE2MaLRu6x8vpieAZpeM46xrTMeY5On/hNhfP U9tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to: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=lL0n728vUIdv161lehfhD3AFeb1S9gcTk2CiLDH/WpA=; b=iqB9edDzaNqx9C1+W5uEto/wDMNieVCQ5QFh1y2yjMwWffqsJUALCsjp6cEjp5bbiz zQEx5WHQ3jP4bSTCDocSnoiFHhhL3wtQp006sbNp19tad9kcyTs+7st3gPWxuoCfgiL7 grI4fRKTlRSLnNAuWQw+xoAR9iCK9wrfxL/ls6soywdaV9l4q7edHP1auIlXYl7n6Mdy QjwTqzK+TFTupYBQRKSr1Snkdm0J79biRgyPzuuGtO9rGp2MHTP6DB9FEILN+zXmlMWP kwTXRiZcgYA+0/Xv4DZMQR/TUgVSq/igJrN/h5xOOcP3XsNtX7DG6EWfvGUKOM+zlvoE N/pA== X-Gm-Message-State: ABuFfojs2cZ5wTm8HP9AcOHLdIfdkEn0B+jjiomEgw1e3/IuDUf1lhgc 0kWXPrwBk+MIrJnmkuRGyNgA6A== X-Google-Smtp-Source: ACcGV63Fb7v+NyG70qhsOodqJn2AEBHg+DazEY4NRpHATXi7ayTr/Tuld+ZDQI5lyUNQmSiuyDMLeA== X-Received: by 2002:a6b:4e19:: with SMTP id c25-v6mr1385169iob.69.1537897041630; Tue, 25 Sep 2018 10:37:21 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a24:ac4d:: with SMTP id m13-v6ls1728605iti.8.gmail; Tue, 25 Sep 2018 10:37:20 -0700 (PDT) X-Received: by 2002:a24:b90a:: with SMTP id w10-v6mr1778454ite.101.1537897040157; Tue, 25 Sep 2018 10:37:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537897040; cv=none; d=google.com; s=arc-20160816; b=gsDvbSKesdX9ZJfJlNdMAuGVhJahjitYXR7WfOsdiSbf9xVqHuYmTiXZ3m/xTi7Fq5 uvFbFWEj0+gZJ8iEqICtwnZUKRyhQKe+GcHwqf0YApm/rt+IcoMUdRj75zmERQ/1Q3OB maoAeNfCMfzy7R9zF2C+OqGXlPyAUrb+/7TqVMGwLxG2n4dlypDt8YfyD7nKwHuPfryl DrdrBDxkyuzlAHhsOkO9NrErMmhP1KlbxGlck18aAcBREpMd+Zg2JIJgOPRc4HjDtGNT N5nfqIBJKThwhLLbYMf5yMexPItdjBXYfU3PF81seBVFK7JtzTEWUoTqFI8fAp+nqJHs P2pw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=smEvB6TWKa33ZHjZV0Ht2B8oP8jIrNr4C9C1xMhFPrY=; b=SWCzcib7jKSnXYpiWY/tIn2HTW0ifH3TwczvI8JjJUgJSgDTdpbmYnhCa80yQAKFcU JC9U88+mijnD95C+gKEGxFh1MFQQ8F2A0XbXW5LJjmf0t0Dx0GcmLPzPBMHon8dBLFYI pJKG+OC70saNLxpHx69w5+KgBTUwow4uA8HRLmxLngYbycmJU9YFHjJMAdLqremJhKQM KbXwr+PeA48BqUCi0iVNwnhU0ymE1IOtZ7HIevD8yCS1lPLEjhMvAWKNgEbAvCGCfCWi k6QrsVY7OJiRAI5RRcCe4bB1xef1C2C2+XKLO7ydGWlhxW5LJcyK3RhlFKov0EyekWpO y/nA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UY0PI2ku; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id c193-v6sor817452itb.127.2018.09.25.10.37.20 for (Google Transport Security); Tue, 25 Sep 2018 10:37:20 -0700 (PDT) Received-SPF: pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 2002:a24:5d0:: with SMTP id 199-v6mr1719096itl.88.1537897039625; Tue, 25 Sep 2018 10:37:19 -0700 (PDT) In-Reply-To: <05c2d528-9837-4968-b19e-42875434962c@isocpp.org> X-Original-Sender: jake.arkinstall@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=UY0PI2ku; spf=pass (google.com: domain of jake.arkinstall@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=jake.arkinstall@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:40220 Archived-At: --000000000000bf83260576b58e3a Content-Type: text/plain; charset="UTF-8" On Tue, 25 Sep 2018, 18:21 , wrote: > Currently we have to use old constructor member initializer list syntax, > if we need to pass parameters in run-time. This is less readable: member > initialization is separated from declaration. > This is a subjective claim. I find the initializer list approach more readable, from a structural point of view. The reason that we can use template arguments in member constructors is that the template argument is in scope and because template arguments are constexpr. That we can do this is completely logical, and that we can't do this with variables is also completely logical. The way I think about proposals is generally "how many confused posts is this going to generate on programming forums?". I think that, although your solution does go some way to solve a stylistic issue, it introduces some conceptual issues surrounding scope. For example, is "n" accessible elsewhere in the class - e.g. can it be referred to within a function? If not, why not? It's in scope after all, and not allowing it would be counter-intuitive to many people. If so, though, what is its behaviour when the value changes elsewhere? If it's a const reference, and the source variable is freed, what happens? How many people are going to add instances of this object to a container in a loop and wonder why they're getting memory access problems? -- 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/CAC%2B0CCPyW-_TdLfrO62q9B2dPFRATXpg8omkphfgDOUFUj9yAg%40mail.gmail.com. --000000000000bf83260576b58e3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Tue, 25 Sep 2018, 18:21 ,<ripopo= v@gmail.com> wrote:

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


This is a subjective claim. I find= the initializer list approach more readable, from a structural point of vi= ew.

The reason that we c= an use template arguments in member constructors is that the template argum= ent is in scope and because template arguments are constexpr. That we can d= o this is completely logical, and that we can't do this with variables = is also completely logical.

The way I think about proposals = is generally "how many confused posts is this going to generate on pro= gramming forums?". I think that, although your solution does go some w= ay to solve a stylistic issue, it introduces some conceptual issues surroun= ding scope.

F= or example, is "n" accessible elsewhere in the class - e.g. can i= t be referred to within a function? If not, why not? It's in scope afte= r all, and not allowing it would be counter-intuitive to many people. If so= , though, what is its behaviour when the value changes elsewhere? If it'= ;s a const reference, and the source variable is freed, what happens? How m= any people are going to add instances of this object to a container in a lo= op and wonder why they're getting memory access problems?

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAC%2B0CCPyW-_T= dLfrO62q9B2dPFRATXpg8omkphfgDOUFUj9yAg%40mail.gmail.com.
--000000000000bf83260576b58e3a-- .