Scope of a top-level let declaration

[seh]

By my reading of the CUE specification, a let declaration occurring at the top level of a file in a package should be scoped to the package. The "Declarations and scope" section of the specification says that

2. The scope of an identifier denoting a field declared at top level (outside any struct literal) is the package block.

It clarifies that aliases occurring at the top level are scoped to the containing file, but it doesn't mention a similar restriction for let declarations.

In my experiments with CUE version 0.4.0, though, I find that a let declaration is only visible within the containing file, and not in another file within the same package. If instead I replace the let declaration with a top-level field, I can refer to it from other files within the same package.

Is my interpretation of the specification wrong? Is the CUE tool enforcing the wrong scope?

[seh]

Based on experience with similar constructs in other languages, I find the CUE tool's file-scoped enforcement to make more sense, because let declarations seem like lexical elements to me, intended to be confined as locally as possible, to only where referring expressions can "see" the declaration. Should we tighten the specification's language accordingly?

[myitcv]

I agree with your analysis. I suspect this is a simple omission from the spec and that point 3 in the "Declarations and Scope" section should read:

The scope of an identifier denoting an alias or let declaration declared at top level (outside any struct literal) is the file block.

Do you want to create a CL/PR to make this change? @mpvl can weigh in at that point, because this point needs to be clarified in the spec at least.

[seh]

Do you want to create a CL/PR to make this change?

Does the spec document live in the repository that sits behind Gerrit? I found some stub files that appear to build it in the cuelang/cuelang.org repository, but not the document itself.

[Time passes ....]

I found the file spec.md here. Is that the one to edit?

[myitcv]

Yes, you found it!

[seh]

Please see my patch in Gerrit.
(What a twisty path to finally be able to upload a patch successfully!)

[myitcv]

Thank you.

What a twisty path to finally be able to upload a patch successfully!

Yes, submitting a CL is initially not as obvious/straightforward as a PR, but with practice it's a very effective and powerful workflow, and the other benefits we get from Gerrit (far superior code review, commit message review, support for stacked changes...) make it a no-brainer. We also plan to do a live stream/recording of how to submit a change via Gerrit to support the docs.

[cueckoo]

This discussion has been migrated to cue-lang/cue#1041.

For more details about CUE's migration to a new home, please see cue-lang/cue#1078.