Public Private members?

[Jonathan M Davis]

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