Add access modifiers

[safield]

It would nice to be have private, protected, and public access modifiers added to the language.

[lrhn]

See fx #757 for proposals on how to add "protected"- and "private"-like features to Dart.

Just adding the modifiers won't do anything if we can't integrate it into how the language actually works. Dart currently doesn't even have the concept of private or protected members, so we'd have to add that as well.

Dart allows you to dynamic invocation. If you have dynamic o = ...; o.foo();, that operation needs to figure out whether you can call foo on that object. If the foo method is declared private or protected on the run-time class of o, then maybe it shouldn't. Unless the current code is ... inside the same class? Or same class hierarchy for protected?
Can a subclass make a protected member public?

Dynamic dispatch is one of the things which makes it hard for Dart to implement "private" and "protected" similarly to, fx, Java. We don't always know the type of the object we are calling the method on at compile-time, and doing that kind of checks at run-time can easily become very expensive.

The Dart model of having library-private names, so it is impossible to even name a method that you don't have access to, works well with dynamic invocation.
If we want other kinds of member access restrictions, it'll probably need to work in some similar way (not necessarily with a prefix like _, but being statically distinguishable in some way).

[leafpetersen]

statically distinguishable in some way

e.g. by declaring them private or protected or something like that? ;)

[lrhn]

e.g. by declaring them private or protected or something like that? ;)

If it can be used to make the distinction at the use-site, where necessary, then sure.

If a name is "private", then it should be to everybody else as if it isn't there. Otherwise the privacy is leaking out. One of the primary uses of private names is to avoid conflicts. I think that's more important than avoiding access.

[XinyueZ]

+1:

• internal class
• class

[mateusfccp]

Well, having _ as the syntax for private elements really sucks. But I don't think it is a trivial task to change this today.

[escamoteur]

I just got bitten by this yesterday, because I hadn't thought of that a private property will not be overridden by a deriving class. I don't know if we even have a lint to warn, that a private property is shadowed which could be unintentional.
So I had to make that property public which it really should not be to make it accessible to the child class and could only add @Protected which is not real protection. Coupling the access right on if you are inside the same library never seemed a good approach to me as it limits you how you organize your files and it is probably a reason why so many Flutter SDK files are so large.

protected properties and potentially a concept of ´friend´ classes would make a lot of design easier while strongly supporting encapsulation and information hiding.