semantics for finding main

[sigmundch]

I keep running into this and I wonder if this is something we can address before 1.0. It's small enough that I think it's doable, but big enough to require some decision making/consensus from the language team.

The current semantics of main is a bit different of what I normally expect it to be. This is in part because we wrote these semantics before we had the notion of 'exports'.

Current meaning:
If you run "a.dart", look and see if the library define by 'a.dart' has a 'main' in it's scope (either because it is defined or imported) and run it.

Meaning I expected:
If you run "a.dart", see if 'a' has a visible 'main' method (defined directly by 'a.dart' or exported from it) and run it.

The following examples illustrate the differences:

b.dart:
  library b;
  main() => print('hi');

a1.dart:
  import 'b.dart';

a2.dart:
  export 'b.dart';

dart a1.dart # prints 'hi'
dart a2.dart # Dart_Invoke: did not find top-level function 'main'.

[gbracha]

The spec does not actually specify the behavior of main() except for scripts. I suppose it should. The question, I take it, is whether to include main() methods that are exported in addition to locally declared ones and imported ones. I can see the motivation. The existing rules for conflicts hsould ensure that the local main takes precedence, that if the same main is imported multiple times no issue will arise, and that if a true conflict due to multiple mains arise the program will issue warnings and fail dynamically.

---

Set owner to @gbracha.
Added Accepted label.

[gbracha]

Fixed in 0.8 spec (revision 29775).

---

Added Done label.

[kasperl]

Filed follow-up bugs:

   dart2js: issue #14762
   vm: issue #14763

Don't know if the analyzer cares about this so CC'ing Brian.

---

cc @bwilkerson.

[bwilkerson]

Yes, it does. Thanks.

analyzer: issue #14770