-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Optional static typing for Starlark #7468
Copy link
Copy link
Closed as duplicate of#27370
Labels
P4This is either out of scope or we don't have bandwidth to review a PR. (No assignee)This is either out of scope or we don't have bandwidth to review a PR. (No assignee)not staleIssues or PRs that are inactive but not considered staleIssues or PRs that are inactive but not considered staleteam-Starlark-InterpreterIssues involving the Starlark interpreter used by BazelIssues involving the Starlark interpreter used by Bazeltype: feature request
Metadata
Metadata
Assignees
Labels
P4This is either out of scope or we don't have bandwidth to review a PR. (No assignee)This is either out of scope or we don't have bandwidth to review a PR. (No assignee)not staleIssues or PRs that are inactive but not considered staleIssues or PRs that are inactive but not considered staleteam-Starlark-InterpreterIssues involving the Starlark interpreter used by BazelIssues involving the Starlark interpreter used by Bazeltype: feature request
Type
Projects
Status
Done
Reading #7428 makes me feel like we have worse of both worlds - dynamic typing without dynamic lookup, or static lookup without type safety. If tooling and safety is a goal of Starlark, and it's ok to diverge from Python spec, what is Starlark's team opinion about optional static typing for Starlark?