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

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.

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;
}

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.

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

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.

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