You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 intfoo(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 finalint 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.
The text was updated successfully, but these errors were encountered:
lrhn
added
the
feature
Proposed language feature that solves one or more problems
label
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
:or a naming strategy:
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:
which is only allowed if the
part x
declaration is in scope. (Referring tox
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.
The text was updated successfully, but these errors were encountered: