www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Public Private members?

reply Flying-Toast <email example.com> writes:
I am not sure if this is a bug or if there is some explanation 
for this behavior, but either way it is confusing and I think it 
should cause an Error.

---
class A {
     private {
         public int a;//No Error???
     }

     private public string s;//Error, expected
}
---

https://run.dlang.io/is/odJDnA
Apr 15
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:
 I am not sure if this is a bug or if there is some explanation 
 for this behavior, but either way it is confusing and I think 
 it should cause an Error.

 ---
 class A {
     private {
         public int a;//No Error???
     }

     private public string s;//Error, expected
 }
 ---

 https://run.dlang.io/is/odJDnA
I would argue that it's indeed a bug.
Apr 15
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 16/04/2019 5:56 AM, bauss wrote:
 On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:
 I am not sure if this is a bug or if there is some explanation for 
 this behavior, but either way it is confusing and I think it should 
 cause an Error.

 ---
 class A {
     private {
         public int a;//No Error???
     }

     private public string s;//Error, expected
 }
 ---

 https://run.dlang.io/is/odJDnA
I would argue that it's indeed a bug.
I would argue that it is not a bug. If it is a bug, then this snippet is also a bug: struct Foo { private: int a; public: int b; }
Apr 15
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 15 April 2019 at 17:59:16 UTC, rikki cattermole wrote:
 I would argue that it is not a bug.
Yes, I agree. A specific attribute should override a group attribute. It is kinda nice for a big block of generally public stuff to have an exception to the rule.
Apr 15
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Apr 15, 2019 at 05:56:31PM +0000, bauss via Digitalmars-d wrote:
 On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:
 I am not sure if this is a bug or if there is some explanation for
 this behavior, but either way it is confusing and I think it should
 cause an Error.
 
 ---
 class A {
     private {
         public int a;//No Error???
     }
 
     private public string s;//Error, expected
 }
 ---
 
 https://run.dlang.io/is/odJDnA
I would argue that it's indeed a bug.
It's a feature. (Though one that I would rather term as a misfeature, since it makes code needlessly hard to read.) The main purpose is to allow you to countermand the 'private' inside a large block of private members. T -- It's bad luck to be superstitious. -- YHL
Apr 15
parent reply bauss <jj_1337 live.dk> writes:
On Monday, 15 April 2019 at 19:10:16 UTC, H. S. Teoh wrote:
 On Mon, Apr 15, 2019 at 05:56:31PM +0000, bauss via 
 Digitalmars-d wrote:
 On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:
 I am not sure if this is a bug or if there is some 
 explanation for this behavior, but either way it is 
 confusing and I think it should cause an Error.
 
 ---
 class A {
     private {
         public int a;//No Error???
     }
 
     private public string s;//Error, expected
 }
 ---
 
 https://run.dlang.io/is/odJDnA
I would argue that it's indeed a bug.
It's a feature. (Though one that I would rather term as a misfeature, since it makes code needlessly hard to read.) The main purpose is to allow you to countermand the 'private' inside a large block of private members. T
The feature would have been much more useful if you could do it with final tbh.
Apr 16
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, April 16, 2019 10:45:52 PM MDT bauss via Digitalmars-d wrote:
 On Monday, 15 April 2019 at 19:10:16 UTC, H. S. Teoh wrote:
 On Mon, Apr 15, 2019 at 05:56:31PM +0000, bauss via

 Digitalmars-d wrote:
 On Monday, 15 April 2019 at 17:38:15 UTC, Flying-Toast wrote:
 I am not sure if this is a bug or if there is some
 explanation for this behavior, but either way it is
 confusing and I think it should cause an Error.

 ---
 class A {

     private {

         public int a;//No Error???

     }

     private public string s;//Error, expected

 }
 ---

 https://run.dlang.io/is/odJDnA
I would argue that it's indeed a bug.
It's a feature. (Though one that I would rather term as a misfeature, since it makes code needlessly hard to read.) The main purpose is to allow you to countermand the 'private' inside a large block of private members. T
The feature would have been much more useful if you could do it with final tbh.
It's a useful feature in general, but it's definitely true that the inability to negate various attributes limits its usefulness, and that's been brought up quite a lot over the years. A good DIP that provided a clean way to negate all attributes would probably be accepted. One problem I do find with this sort of practice though is that when people start dong stuff like safe: at the top of a file or or type declaration and then negate it with system or trusted on specific functions, it becomes very easy to think that attributes aren't applied when they actually are. It also doesn't work well with templates, because we don't have a way to indicate that they should use attribute inference for a particular attribute instead of using the attribute that was mass-applied to the file or type. So, personally, I mostly avoid using : or {} with attributes. The main exception would be public/private/protected, but even that has caused problems sometimes when other people have worked on my code, because they don't realize that a particular access level was already applied. So, while I definitely think that we should improve our ability to negate attributes and indicate that an attribute is inferred when it was mass-applied, I am afraid that it would lead to people mass-applying attributes in ways that would lead to maintenance problems that wouldn't exist if the attributes were just applied explicitly to each function. Most people don't like having to apply all of those attributes though. - Jonathan M Davis
Apr 18