Create @private, just like we have @protected

[marcglasberg]

We should have a @private annotation, since it's unlikely we'll ever have the private keyword (#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 #33383.

[kevmoo]

CC @lrhn

[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).

[marcglasberg]

@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 #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.

[Ing-Brayan-Martinez]

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

[rydamerell]

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).

Python does this and is one of the most widely used programming languages in the world, so it's not as though this design pattern hinders language adoption. I understand the desire for something with its function explicit so you can understand what it means without being familiar with the language, but I believe it works for the most part if you're familiar with a few of the most popular programming languages.

After all, even C uses underscores before identifiers and tokens that the designers want people to use sparingly if at all. Look at the compiler provided __cdecl and __asm__(), or the ever common design pattern of typedef struct _linkedlist {int item; struct _linkedlist* next;} LinkedList;. Not an official part of the language but very prominent in the C ecosystem.

[feinstein]

@private could also be useful for avoiding the boilerplate of defining a private variable that is referenced in a named constructor:

class LocalStorageDataSource {
  LocalStorageDataSource({required FlutterSecureStorage secureStorage}) : _secureStorage = secureStorage;

  final FlutterSecureStorage _secureStorage;

It could be just:

class LocalStorageDataSource {
  LocalStorageDataSource({required this.secureStorage});

  @private
  final FlutterSecureStorage secureStorage;

The difference might seem small, but most this code is auto-generated by the IDE (e.g. "add final fields missing parameters") so it makes a big difference on the amount that we type.

I use @visibleForTesting which achieves the same practical function, but wanted to share my 2c on this.