Propose rules about main for null-safety

[eernstg]

This is a proposal for new rules about main, adding a new section in the null safety spec (which will replace the section 'Scripts' in the language specification in the future).

Potentially noteworthy aspects (compared to this):

This proposal maintains that the initial function has the name main. I think it's helpful for developers to know for sure that the initial function has this name, so that they don't suddenly have to use some other name, just because they have switched to use a different compiler.

This proposal still defines the term script; however, it is now a very straightforward concept. If we think the word 'script' sounds too "PHP-ish" then we can rename it (here, and later in the language specification in general), but it seems reasonable to be able to talk about the ability to be the provider of the function that defines what it means to run a program (the "initial function").

I have preserved the specification of how to invoke main (with 2, 1, or 0 arguments), but broadened it to allow implementations to pass additional arguments. This means that an embedder can allow or require main to have additional optional parameters (positional or named), and it can pass whatever actual arguments it wants to those additional parameters.

But we do maintain that T main() for any T, T main(U u) where List<String> <: U, and T main(U u, V v) must work (except for the catchall clause that "implementations can have arbitrary extra constraints on the signature of main"). Also, all invocations must enforce the declared types, and we do statically prevent weird signatures like void main(int i) and void main(arg1, arg2, arg3).

[lrhn]

How does this actually differ from what we have now?

The only difference I see is that we can now pass more arguments if we want to.

[eernstg]

Review response.

[eernstg]

@lrhn wrote:

How does this actually differ from what we have now?

It specifies that it is a compile-time error to have a first positional argument whose type isn't a supertype of List<String> (so we get static errors for a case like void main(int args)). It allows the positional parameters to be optional (allowing void main([List<String> args]) and similar signatures which used to be a compile-time error), and it allows additional optional positional parameters (making the spec text allow signatures that the implementations actually allow today). It also allows optional named parameters (again, allowed today by implementations).

It allows implementations to add their own constraints on the signature of main (which is desired by the dart2js team), but hints that such constraints should be reasonable. It's a matter of good taste to ensure this.

Finally, it specifies that dynamic errors must occur such that the invocation of main is type safe in the sense that actual arguments must have the declared parameter types. I claimed that this would be implied because it is just another function call (and all of them must be sound), but it could be argued that the invocation of the initial function is somehow a "special" function call which is not automatically covered by the existing rules. The text given here makes it explicit that we do have the guarantee for that kind of soundness.

[eernstg]

@leafpetersen, @rakudrama, @natebosch, do you have further comments on this PR?

[johnniwinther]

This excludes getters, right? co19/Language/Libraries_and_Scripts/Scripts/top_level_main_t05 seems to assume it doesn't.

[eernstg]

It is intended to exclude getters. The old version of this text in section Scripts said explicitly in commentary that we couldn't have a 'top-level getter or field named main', and we did not discuss nor intend to change that when this spec change was landed.

However, section 'Functions' implies that 'function' includes getters, setters, constructors, and "functions" (no, we don't have a separate term for the ones that have a <formalParameterList> and aren't constructors, I had a CL a long time ago to fix that, but it hasn't been landed). So the text should say unless _D_ is a non-getter function declaration. It can't be a top-level constructor and a setter can't have the name main, so that should be enough.

[eernstg]

Edit: #1248

[rakudrama]

When calling main from external code, e.g. JavaScript, it is necessary to convert arguments. We can't just say that main is called dynamically from 'outside'. This conversion happens in the context of the program but before entering main, e.g. needs to access the type List<String> for that program. This interstitial place a special place that we want to constrain heavily in a platform dependent way. For dart2js we want limit the conversion to just Array-to-List<String>, for which we need to know the static type of the entry point.

[leafpetersen]

@rakudrama does line 920 not address your concerns?

[rakudrama]

Yes, it does. I was just adding colour for Johnni.