Language: 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.