We should have a @private annotation, since it's unlikely we'll ever have the private keyword (https://github.com/dart-lang/sdk/issues/33383), just like most languages do.
It wouldn't really make it private in the _ sense, but the IDE would warn us if we use it outside of the class. That's what it does with @protected.
That would be very helpful because adding _ is not very clean-code, and we have a lot of code which remains public for that reason.
That's also very easy to implement.
There's no reason for us to have @protected and not @private, since _ is not a good solution, but just a compromise for performance reasons as explained in https://github.com/dart-lang/sdk/issues/33383.
CC @lrhn
I'm not sure what problem this will solve.
The @protected solves a problem because it is an access control that spans libraries. Some accesses are allowed and others are not.
A @private annotation would restrict access to the same class, which is in the same library, so the member should already be library private.
The only advantage suggested here is to not need to write _ in front of the name because the author does not seem to like it ("not very clean-code"). Using underscores is, however, idiomatic Dart, not something to be worked around.
I do not want people to use @private int foo over int _foo. Mostly because it won't work - library privacy protects against name collision, this does not.
I see no positive outcome of adding this annotation. Any use of it is either going to be library private already, in which case the annotation provides very little protection - only against the author of the library who can remove the annotation at will - or it's going to not be private, and then it's fundamentally flawed.
(It's an annotation, though, so I can't actually stop anyone from adding it. I just highly recommend not doing so).
@lrhn Sure I don't like it. It makes code difficult to read. Some code ends up with hundreds of useless _. Dart is the only language I know of that instead of time-honored accessor keywords uses a naming convention and an annotation (maybe there are others I don't know of).
You say you do not want people to use @private int foo over int _foo but shouldn't this be the developer's decision? If I had this option I'd continue to use _ for my packages, and would use @private for our regular internal app code where an IDE warning is more than enough protection.
I just opened this issue because https://github.com/dart-lang/sdk/issues/33383 was closed. Dart was not a very popular language before Flutter, and I believe it's a missed opportunity not trying to understand why and fix those problems.
The use I see for the @private or @proteted annotations and perhaps @public is to help the dart language interoperability for transpilation processes to languages like java or swif, and it would also be useful for a better understanding of ides like Intellij Idea or Android Studio for class attribute scopes
Most helpful comment
@lrhn Sure I don't like it. It makes code difficult to read. Some code ends up with hundreds of useless
_. Dart is the only language I know of that instead of time-honored accessor keywords uses a naming convention and an annotation (maybe there are others I don't know of).You say you do not want people to use
@private int foooverint _foobut shouldn't this be the developer's decision? If I had this option I'd continue to use_for my packages, and would use@privatefor our regular internal app code where an IDE warning is more than enough protection.I just opened this issue because https://github.com/dart-lang/sdk/issues/33383 was closed. Dart was not a very popular language before Flutter, and I believe it's a missed opportunity not trying to understand why and fix those problems.