Support C++ style friend semantics

[DartBot]

This issue was originally filed by yahuja...@google.com

---

Consider the following set of classes:

library foo.model;
class FooModel {
  int _bar;
  int _baz;

  FooModel(this._bar);

  int get bar => _bar;

  int get baz => _baz;
  set baz(int val) { _baz = val; }
}

library foo.service;
class FooService {
  RpcMaker _rpc;

  FooService(this._rpc);

  FooModel createFooModel() {
    var model = new FooModel(2);
    return _rpc.getXForFoo().then((val) => model.baz = val);
  }
}

library foo.user;
class FooUser {
   FooUser(FooService service) {
     var model = service.createFooModel();
     print(model.bar);
     doSomething().then((_) => print(model.baz));
   }

   Future doSomething() {
     // Make some RPC or something.
   }
}

The thing of note here is that I have some object I need to initialize asynchronously after an RPC is made. Since FooService is in a different library from FooModel, I have to expose the baz setter in order to allow FooService to set it. I also cannot make FooService return a Future<FooModel>, since I need to use the synchronously provided value of bar.

I think a good solution for this problem would be to specify that my FooService class is a friend of the FooModel class, thus allowing me to set the internals without having to resort to a Builder/View pattern.

Another major reasong adding C++ friend classes could be useful is in testing.

[DartBot]

This comment was originally written by yahuja...@google.com

---

Er, a mistake in the above. _rpc.getXForFoo() should be _rpc.getBazForFoo()

[DartBot]

This comment was originally written by yahuja...@google.com

---

Sorry, another correction.
createFooModel() returns a future in what I wrote above. It should be:

FooModel createFooModel() {
  var model = new FooModel(2);
  _rpc.getXForFoo().then((val) => model.baz = val);
  return model;
}

[lrhn]

Added Area-Language, Triaged labels.

[zoechi]

What about just analyzer support, for example with an @internal annotation, which allows only access for code from within the lib/src and test directory. Similar to the recently introduced @protected.

I have a large API where everything needs to be accessible internally, but for references passed out to the user the auto-completion of the IDE should only list what the user is supposed to use. The analyzer should hint/warn about access to internal members.

Runtime semantics don't concern me.

Wrapping everything with proxies that only provide a subset of the members before passing a reference is just too cumbersome.

part/part of is a step-child of Dart and some of the Dart team discourage it's use.
This also would make it easier for generated code to be part of "internal" to share access.

Placing classes outside and inside of lib/src doesn't help either, because a subset of the members of a single class should be @internal while the rest should be public.

[matanlurey]

There are several other concurrent threads on friends or internal or visibility options.

[xgqfrms]

dart part

https://dart.dev/guides/libraries/create-library-packages#organizing-a-library-package