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

disallow recursive references for block-scoped bindings #2309

Merged
merged 3 commits into from
Mar 12, 2015

Conversation

vladima
Copy link
Contributor

@vladima vladima commented Mar 12, 2015

Fixes #2188

@@ -203,6 +203,33 @@ module ts {
isCatchClauseVariableDeclaration(declaration);
}

export function getEnclosingBlockScopeContainer(node: Node): Node {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did anything change here (can't tell cuz it moved)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no, code was just moved from emitter to utilities

@vladima
Copy link
Contributor Author

vladima commented Mar 12, 2015

All TypeScript errors are effectively warnings since they never block emit

@JsonFreeman
Copy link
Contributor

@mihailik, your point is true of type errors as well, but we still report static errors for them. The idea is that we report an error on something if it will be an error when/if you get there.

@JsonFreeman
Copy link
Contributor

👍

vladima added a commit that referenced this pull request Mar 12, 2015
disallow recursive references for block-scoped bindings
@vladima vladima merged commit 17d2a1b into master Mar 12, 2015
@vladima vladima deleted the recursiveLetConst branch March 12, 2015 20:20
@mihailik
Copy link
Contributor

Let-recursivity is statically unknown in a general case, here's a very simple example:

let x = someFunc() > 0.9 ? x : 10;

For type errors the intention behind the code is very clear: type specification is a promise by the code writer. If it statically breaks, it's safe to point out a broken promise.

For let-recursivity cases, it's not as clear what is intentional and what is not. And much worse, there is no syntax to silence the checker (for type checks you can always cast to < any >).

@mihailik
Copy link
Contributor

Judging by the code and tests, the current behaviour is to report an error if x is used in its own initialiser expression, except for when it's used inside a function expression.

That sounds a reasonable balance to limit false positives and false negatives to edge case minority.

Being such a non-trivial error, it would be great to call out this validity check in the TS spec.

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Recursive let/const references should error
6 participants