spec: clarify behavior of load statements within toplevel if/for blocks

[alandonovan]

The spec is unclear about the behavior of load statements outside a function but inside a top-level if/for block. (The Java implementation does not permit top-level if/for blocks at all, so it doesn't provide any precedent.)

Currently, it is not an error:

$ starlark -globalreassign
Welcome to Starlark (go.starlark.net)
>>> for x in ():
...   load("x", "f")
... 
>>> if False:
...   load("x", "f")
... 

Disallowing it would make load statements behave more like imports in a static language (Go/C++/Java): as declarations of the program structure. Allowing them would allow for delayed or conditional loading, as in Python. However, it would complicate applications (like Bazel) that preprocess all the load statements as they would have to search within if/for blocks to find them.

My inclination is to disallow it, and I'm sure @laurentlb would agree, but I'm a little worried I have inadvertently allowed Go clients to start depending on this feature. Oops.

[fenollp]

How about a package flag that defaults to preserve current behavior for go clients?

I’d like my Go client to set the flag to false so would love to have this upstream.

Thanks for catching this

[alandonovan]

Pierre, do you mean you would set the flag to preserve the current behavior, or to enable the stricter check? If the latter, could you explain what you use this feature for?

[fenollp]

Ah I can see how I was unclear, sorry about that.
I'm voting to disallow it and I'd like a way to make sure such loads are forbidden.

[alandonovan]

Glad to hear it. I'm tempted to make the change and see if anyone complains.