220 26530 <7145a8aa-6a74-4ff3-8984-4a74aef66b5d@isocpp.org> article Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?=C3=93lafur_Waage?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Adding a const qualifier to class access modifiers Date: Sun, 3 Jul 2016 18:25:42 -0700 (PDT) Lines: 152 Approved: news@gmane.org Message-ID: <7145a8aa-6a74-4ff3-8984-4a74aef66b5d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1804_283435731.1467595542727" X-Trace: ger.gmane.org 1467595558 24464 80.91.229.3 (4 Jul 2016 01:25:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 4 Jul 2016 01:25:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC4MN3EXRIDRBF7W425QKGQEO7C3KLA@isocpp.org Mon Jul 04 03:25:48 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f69.google.com ([209.85.214.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bJsdu-0007FK-0W for gclcip-std-proposals@m.gmane.org; Mon, 04 Jul 2016 03:25:46 +0200 Original-Received: by mail-it0-f69.google.com with SMTP id f6sf153006909ith.1 for ; Sun, 03 Jul 2016 18:25:45 -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: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=7mez9idcmfHFId8xRT1mTxhu1SIGnmzGjTFI5NHmaNE=; b=aP5/WQbh6320na0ydyOBORgDzjppz0X/phGP+MkheaBqt3GmwqPOCEXl9HNzmHvRjj MAgXr2kM/8nB4QEWJCA/8Qa6hYl6VlA/R/V3fXfOj9DGMnR1/MnINWGjwYy7m8yNWADr vICqcJH9okVGohSMVUhCemkhKUBEUKFiCrnorZieZgj2AFVBQzqAqzkcyYD+Y8nEA55F x0gZwgpJs/v8Umznxc5P+6QVZEBAQrfKk72kI5MPEncedJbM+qesVVCQf6WvNfdiPTNH HYqTe5kt3YnHZsKjhrzMLJxSDBfqynD07IRcQ4WYSQYq91rnaIs1wR5s2eiloXoRiE/a qIgw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id: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=7mez9idcmfHFId8xRT1mTxhu1SIGnmzGjTFI5NHmaNE=; b=b2mQlkx2WjlHvw/MSlagwdqxCFEpllcKy+mE/NnmD6Vn1KkK33I+xvoF/EtGS9IFuy Uee+p+DuWrCtChmkUySwVVlDOq7MsVf0WSVzaRUWIJUKKvHpjftAW3oNBQWp1Gd0AwcF nBCy3j/jJXfAPffRhu7Oz9AXZgYr/jcU3kOazUUSc610AA+Nz9l2D/yKcbRXn3aetlRg nBw+VRd68m5c5U3ODvq0ORJuXMqtE6+DP00eOCJtWc0YOrgfd1WZjOWa1IByoSYDMmCB ib9Q7YrbDeKryDYC9aRyUCi74lyiZM+C/iijuyLTCFGD2SGevetZnYfEu4ONo337fK7t f91g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id: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=7mez9idcmfHFId8xRT1mTxhu1SIGnmzGjTFI5NHmaNE=; b=DYfNGdXar+3vR7EThNAQpBSe6LTgznUSyz41fi8ZOKBFTGuU84dTUJpw2bWIGwaSvQ FhiD3T9m0yTEgnQj6hiufxRsfPEdA/SatOIT2Pbyp6ioxo4/c/ZbRbDvdtNPYNiZv+tA NAf2xmhJprrrpx1fQtQuviaLFoMM9XXHN3x0hAXkh5f6OABY7PP7KjohdS9ecIgLE9jw VkfMxghjnhqa6KMIlSPWESkd67gajmCJvhAVm1baRIDBWqi/DaTkEGnqfZe7bwuA50Ih yHduGJXkBTnyNTJ14U28/qK3I8e5LvKeAp/pQG3sFDCg+qtH4nvTF7tKP54N9q4efF1d KDAA== X-Gm-Message-State: ALyK8tIvsF/VBS8nzPKkOjBeAfSuKiqPT8DL9fO5aM/Y2c6P62j8CZYXQaPKnjwflrDKvA== X-Received: by 10.157.0.4 with SMTP id 4mr28632802ota.5.1467595544972; Sun, 03 Jul 2016 18:25:44 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.36.127.69 with SMTP id r66ls625078itc.9.canary; Sun, 03 Jul 2016 18:25:43 -0700 (PDT) X-Received: by 10.36.8.7 with SMTP id 7mr219973itc.8.1467595543658; Sun, 03 Jul 2016 18:25:43 -0700 (PDT) X-Original-Sender: olafurw@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:26530 Archived-At: ------=_Part_1804_283435731.1467595542727 Content-Type: multipart/alternative; boundary="----=_Part_1805_236353798.1467595542727" ------=_Part_1805_236353798.1467595542727 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One of the biggest things I have seen in developing medium to large scale= =20 systems is how useful const is to show the original author's intent, that= =20 this value should not be changed, even by grabbing a mutable variable and= =20 creating a const auto& temporary and using that temporary to state that=20 this value should stay the same. This get's tricky when dealing with class members, especially when=20 accessing them from the outside. Should you limit access via private and provide a Get function? - Writing all those Get type functions can get tiring and bloats the class= =20 with very trivial functions, even if they return a copy or a const ref. Should you keep it public and take the python stance of "we're all adults= =20 here"? - Opening the access to anyone outside can later down the line introduce=20 errors if it's a value that needs to be updated in a certain way to keep=20 the internal state of the class sane. My idea to throw out there is to suggest "const public:" or "public const:" Any member defined after "const public:" has an automatic const qualifier= =20 to anyone accessing the member externally. Here is an quick example I threw together. https://gist.github.com/olafurw/693edb5aed460cd9468d52184a406d95 This removes the need to write any get functions=20 and shows the authors intent that you can read this value as you wish but= =20 you can't change it thus keeping the internal state sane. Same thing can be done with protected where the child class can read but=20 not modify values of the parent without the need of extra functions. Possible issues would be: - Adding extra layer to the access modifiers might be unnecessary=20 complication, might think that it means that the members are const, not=20 that they are const only to the public (valid point but convention has been= =20 to put const before the types so it might not be a big issue) - You have to check the header file to know if a member is public or const= =20 public (this is true and could be alleviated by naming conventions and IDE= =20 hints, but still we should not rely on those) - Casting away the const to get modifiable access to the member (true as=20 well but if you were providing a const Foo& GetFoo() function before then= =20 you are open to that anyway) - What about functions or static members defined after the "const public:"= =20 access modifier? (they would be given the const qualifier on external=20 access as well) Thanks for reading and I hope I was able to describe the idea clearly as=20 it's my first post :) Cheers, =C3=93lafur Waage @olafurw --=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/7145a8aa-6a74-4ff3-8984-4a74aef66b5d%40isocpp.or= g. ------=_Part_1805_236353798.1467595542727 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One of the biggest things I have seen in developing medium= to large scale systems is how useful const is to show the original author&= #39;s intent, that this value should not be changed, even by grabbing a mut= able variable and creating a const auto& temporary and using that tempo= rary to state that this value should stay the same.

This= get's tricky when dealing with class members, especially when accessin= g them from the outside.

Should you limit access v= ia private and provide a Get function?
- Writing all those Get ty= pe functions can get tiring and bloats the class with very trivial function= s, even if they return a copy or a const ref.

= Should you keep it public and take the python stance of "we're all= adults here"?
- Opening the access to anyone outside can la= ter down the line introduce errors if it's a value that needs to be upd= ated in a certain way to keep the internal state of the class sane.

My idea to throw out there is to suggest "const publ= ic:" or "public const:"

Any member = defined after "const public:" has an automatic const qualifier to= anyone accessing the member externally.

Here is a= n quick example I threw together.

https://gist.git= hub.com/olafurw/693edb5aed460cd9468d52184a406d95

This removes the need to write any get functions=C2=A0
and sho= ws the authors intent that you can read this value as you wish but you can&= #39;t change it thus keeping the internal state sane.

<= div>Same thing can be done with protected where the child class can read bu= t not modify values of the parent without the need of extra functions.

Possible issues would be:
- Adding extra lay= er to the access modifiers might be unnecessary complication, might think t= hat it means that the members are const, not that they are const only to th= e public (valid point but convention has been to put const before the types= so it might not be a big issue)
- You have to check the header f= ile to know if a member is public or const public (this is true and could b= e alleviated by naming conventions and IDE hints, but still we should not r= ely on those)
- Casting away the const to get modifiable access t= o the member (true as well but if you were providing a const Foo& GetFo= o() function before then you are open to that anyway)
- What abou= t functions or static members defined after the "const public:" a= ccess modifier? (they would be given the const qualifier on external access= as well)

Thanks for reading and I hope I was able= to describe the idea clearly as it's my first post :)

Cheers,
=C3=93lafur Waage
@olafurw

--
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/7145a8aa-6a74-4ff3-8984-4a74aef66b5d= %40isocpp.org.
------=_Part_1805_236353798.1467595542727-- ------=_Part_1804_283435731.1467595542727-- .