Enhance Visibility Control with @private and @public Annotations in Dart

[stan-at-work]

It would be nice if we could annotate a normal property with a @private or @public annotation to declare its visibility.

This way, we wouldn't have to struggle with the, in my opinion, impractical underscore convention for visibility. While it’s a clever approach, it’s not very practical.

Example: Current Dart Visibility Convention

In Dart, you use an underscore _ to mark a property as private within the library:

class Example {
  String publicProperty = "I am public";
  String _privateProperty = "I am private";

  void display() {
    print(publicProperty); // Accessible
    print(_privateProperty); // Accessible
  }
}

However, this convention relies on naming rather than explicit annotations, which can be error-prone or less readable.

---

Proposal: Use Annotations for Visibility

Imagine if Dart allowed visibility annotations, making code more explicit and standardized:

class Example {
  @public
  String publicProperty = "I am public";

  @private
  String privateProperty = "I am private";

  void display() {
    print(publicProperty); // Accessible
    print(privateProperty); // Accessible
  }
}

With annotations, changing visibility would be cleaner and would not require renaming properties. For instance, switching privateProperty to public would be as simple as changing the annotation:

@public
String privateProperty = "I am now public";

---

This approach could make visibility declarations more robust and readable, reducing potential naming conflicts and confusion. It would also integrate better with modern language features like metadata or decorators.
If Dart supported @private and @public annotations for visibility, a couple of issues with the current implementation would completely disappear.

[TekExplorer]

This is strictly worse than what we have now.

The underscore is actually rather readable. You see an underscore? Its private. No need to check what annotation it has. No need to go to the original declaration in code review to check.

That said, I do think that adding this wouldn't be bad, especially for cases like UnmodifiableList which may want to hint to the analyzer that the modification functions should be hidden from auto complete and warned against if it's used anyway.

Granted, that may just be @internal or some other existing annotation, but those are my 2¢

[lrhn]

It's not a new idea to add declared public, private and or protected access modifiers, rather than only having library privacy.
It has generally not been considered a good design choice for Dart, and not a real improvement over library privacy.
The only think library privacy can't do is protected access.

One of the advantages of having different names for private members is that it avoids naming conflicts.
If you use access modifiers, you may not need to to rename variables when going from public to private,
but you risk the private member having the same name as a public member from somewhere else.
Privacy is both about controlling accessibility and about avoiding name conflict between things you can access and things you can't. Because you shoulnd't need to know about the latter at all.

Existing issues include:

• Public, Private and Protected Access Modifiers #3289
• Add public and private access modifiers to language #1446
• About the Dart lang assignment of class private member variables and method #855
• Add access modifiers #835
• Add protected. #2571
• Add a protected keyword for real protected access (instead of the @protected annotation) #1026

And other approaches to the same issue, like.

• Protected instance members #3825

Using annotations would not be a language feature. Annotations won't be able to change the meaning of a program.
So any language feature won't be using that syntax.