220 40221 article Path: news.gmane.org!.POSTED!not-for-mail From: random.romik@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Primary constructors for C++ ? Date: Tue, 25 Sep 2018 10:52:02 -0700 (PDT) Lines: 130 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/mixed; boundary="----=_Part_2485_1149589954.1537897922499" X-Trace: blaine.gmane.org 1537897799 25898 195.159.176.226 (25 Sep 2018 17:49:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Sep 2018 17:49:59 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCCZP3OF64HBBQ7LVHOQKGQE3NZ4JPY@isocpp.org Tue Sep 25 19:49:55 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yb1-f197.google.com ([209.85.219.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1g4rT8-0006dL-VL for gclcip-std-proposals@m.gmane.org; Tue, 25 Sep 2018 19:49:55 +0200 Original-Received: by mail-yb1-f197.google.com with SMTP id 203-v6sf10674976ybf.19 for ; Tue, 25 Sep 2018 10:52:05 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=qYyP8yjgj0IGdmiqR/3+8FQ0d6yYNSyD4E+HE+3JNpU=; b=Nl19O+mTt5IcvUnHJC9f6Tt0M+H4QwbkWkRNuReVjIjuHQtP2lfQz1ZwWOH8XgrdFL EVXKL7JIjghqDR02QS7ZSf5xG88Z7K4/C3auOMYLFlk+AsBM33GvzKLN4R568Yq2it3b 5WykoLOcMKEfADzpc8C61kIBI8dhqh5vVrsH0vqYXW/szfEKxMj7hdIWu4SHGewYcX0D aotogZUzfkVRHS/t4S05X6hThTUU3c5oZ6rvVHg/22vDFrW26NfwtWmiENwyiyTX0OYQ vL5d4rqDfBJkhnF6lIANJJAh2t0TEaeVGQTLYnmrZ3OZX1tszc+OQQyb5gVBW7lKdcNh k3Eg== 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=qYyP8yjgj0IGdmiqR/3+8FQ0d6yYNSyD4E+HE+3JNpU=; b=LcK9nJiWJdipoU0i0mU0RYVtwevDPSss3uj69xVv+GAT3ny72+MWWi1jBx/iMjWEjI t3xzd8DgZuM/NvPRsiV6az221SjKG7WVqPAUn74D0rprikq46pcdOACRn197IWQ6gzns 7hwQDIkZurJKwOGW8LU0SKWDtcO5z9833y5dVPpYSEOUERyWM8xnTIuZnpdKWmk2oc7G JomhsDDakzHx7st1NX0gHll8Gajz/zhEejFK6eRa84WMjd2+KOsiCUmJW9v91lUBMM+o e6UmB8ak6HdOkGou2OSteaTp7okOlqNs0klu+Hr+CIqFIkULYc1/aNhjtxxfJs7lQop0 CIzA== 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=qYyP8yjgj0IGdmiqR/3+8FQ0d6yYNSyD4E+HE+3JNpU=; b=E5Z6KTwVRn9k10oZUlGm7eLaQVEv9hT92r4C2ilQV2fUXn54oY8AieiDnM63lykt0n mPJp/gz2saUVn5UJN9Q6NYUmrJvArBFTv4+0ms4pWBdJSmqN5XHC/qF1r5WQMbxqE15e ddJU7yz2TJZoOoSCZzjAqpsIKNo9rWu4qaoTFyQfrApEra2ZiY9L9f+wAMVUNewh66n3 kxdR2PaMCB6iO189moPBdiyuxN759rtY0y3rTdZN9OrSzJcF4juyXPCxbako4GhXcHbP 2YECbNS/+zCYxJGXiLrpbEH5E5wGb3/MdvlF3z+4FQwWvtm/jeWY/l9TN+HeGYWBioQG WRig== X-Gm-Message-State: ABuFfogJDoKqY+vR74UDnKprEY6JmpuvPNn+I2T3uvokTQtp2CIfiHDZ SVeaRtvPEn7v7/2GzjDF2mtWnQ== X-Google-Smtp-Source: ACcGV63Z8hr3yyxn4jeNkgjNWQePFytwHw1tgX8llPWtxJFfNyGFUWwPq4YFScEFOkQZGcFb39hGvg== X-Received: by 2002:a25:3b8c:: with SMTP id i134-v6mr116388yba.33.1537897925011; Tue, 25 Sep 2018 10:52:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:b9c6:: with SMTP id y6-v6ls2666876ybj.4.gmail; Tue, 25 Sep 2018 10:52:03 -0700 (PDT) X-Received: by 2002:a25:2483:: with SMTP id k125-v6mr27355ybk.5.1537897923437; Tue, 25 Sep 2018 10:52:03 -0700 (PDT) In-Reply-To: X-Original-Sender: random.romik@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:40221 Archived-At: ------=_Part_2485_1149589954.1537897922499 Content-Type: multipart/alternative; boundary="----=_Part_2486_409632890.1537897922499" ------=_Part_2486_409632890.1537897922499 Content-Type: text/plain; charset="UTF-8" On Tuesday, September 25, 2018 at 10:37:22 AM UTC-7, Jake Arkinstall wrote: > > 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. > > Thanks for feedback, good point. I agree that syntax perception is subjective. > 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? > n should only be accessible in initializers, because in-class member initializers are parts of object construction. This feels very intuitive to me. On the other side old syntax is sometimes not intuitive and error-prope : consider for example -Wreorder related bugs. -- 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/d37ec4f7-57d1-4802-8549-e49fb5f620fc%40isocpp.org. ------=_Part_2486_409632890.1537897922499 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tuesday, September 25, 2018 at 10:37:22 AM UTC-= 7, Jake Arkinstall wrote:
On Tu= e, 25 Sep 2018, 18:21 ,<rip...@gmail.com> wrote:

Currently we have to use old constructor member initializer lis= t 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 templat= e arguments are constexpr. That we can do this is completely logical, and t= hat we can't do this with variables is also completely logical.

The way I think about proposals is generally "how many confuse= d posts is this going to generate on programming forums?". I think tha= t, although your solution does go some way to solve a stylistic issue, it i= ntroduces some conceptual issues surrounding scope.


=C2=A0Thanks fo= r feedback, good point. I agree that syntax perception is subjective.
=C2=A0
For example, is "n= " accessible elsewhere in the class - e.g. can it be referred to withi= n a function? If not, why not? It's in scope after all, and not allowin= g 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 t= o add instances of this object to a container in a loop and wonder why they= 're getting memory access problems?

n should only be accessible in initializers, because in-class memb= er initializers are parts of object construction. This feels very intuitive= to me.

On the other side old syntax is sometimes = not intuitive and error-prope : consider for example -Wreorder related bugs= ..

=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/d37ec4f7-57d1-4802-8549-e49fb5f620fc= %40isocpp.org.
------=_Part_2486_409632890.1537897922499-- ------=_Part_2485_1149589954.1537897922499-- .