Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Part-private variables. #3746

Open
lrhn opened this issue May 1, 2024 · 1 comment
Open

Part-private variables. #3746

lrhn opened this issue May 1, 2024 · 1 comment
Labels
feature Proposed language feature that solves one or more problems

Comments

@lrhn
Copy link
Member

lrhn commented May 1, 2024

If/when we introduce part files with their own imports, it might also be useful to allow the part file to define its own part local declarations.

A part-local declaration does not become part of the library's declaration scope, is not exported (even if it's publicly named), and is not available to a parent or sibling file.

A part local declaration cannot have the same base name as library member declaration or an import prefix declared in the same file (or another part local declaration in the same file, unless one is a getter and the other a setter, as usual). The declaration lives in the same scope as the import prefixes declared by the current file, which is also inherited by sub-parts.

The declaration is therefore visible in sub-part files, if they do not import or declare an import prefix or their own part-local declaration that shadows it. (It's a goal that a parent file import or, now, part-local declaration can be ignored in a part file, if it declares or imports its own meaning for the name.)

All this, and no syntax yet. I don't have a good syntax.
Options are a prefix modifier, maybe part:

 part final x = 42;
 part int foo(int x) => x;
 part const banana = "yum";

or a naming strategy:

  final __x = 42;
  int __foo(int x) => x;
  const __banana = "yum";

or something completely different.

With augmentations, is it possible to augment a part private declaration?
Maybe. It's probably not a problem, the declaration is just like any other declaration, it's just scoped to only a certain number of files, and isn't exported. (An implementation strategy could be to rename the declaration to a fresh private name.)
If we can augment, then it's probably something like:

augment part final int x = 21;

which is only allowed if the part x declaration is in scope. (Referring to x at this point will refer to the same name as the declaration it augments.)

It's tricky, and maybe better to not allow augmenting, so that a part private declaration can be trusted to mean what it says in the current part file.

@lrhn lrhn added the feature Proposed language feature that solves one or more problems label May 1, 2024
@cedvdb
Copy link

cedvdb commented May 3, 2024

What about a "private" keyword ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Proposed language feature that solves one or more problems
Projects
None yet
Development

No branches or pull requests

2 participants