Allow protected members to be accessed within the enclosing class #60001
+230
−1
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Andarist
commented
Sep 18, 2024
| @@ -33868,7 +33868,7 @@ export function createTypeChecker(host: TypeCheckerHost): TypeChecker { | |||
| // get the original type -- represented as the type constraint of the 'this' type | |||
| containingType = (containingType as TypeParameter).isThisType ? getConstraintOfTypeParameter(containingType as TypeParameter)! : getBaseConstraintOfType(containingType as TypeParameter)!; // TODO: GH#18217 Use a different variable that's allowed to be undefined | |||
| } | |||
| if (!containingType || !hasBaseType(containingType, enclosingClass)) { | |||
| if (!containingType || !hasBaseType(containingType, enclosingClass) && !isNodeWithinClass(location, getClassLikeDeclarationOfSymbol(getParentOfSymbol(prop)!)!)) { | |||
There was a problem hiding this comment.
the added check is the same one as for private properties a couple of lines above this (in this function)
There was a problem hiding this comment.
It does besides the null checking; is it really safe to ! all of these? The other case doesn't.
There was a problem hiding this comment.
The other case does exactly the same. I copy-pasted this :p
// Private property is accessible if the property is within the declaring class
if (flags & ModifierFlags.Private) {
const declaringClassDeclaration = getClassLikeDeclarationOfSymbol(getParentOfSymbol(prop)!)!;
if (!isNodeWithinClass(location, declaringClassDeclaration)) {
if (errorNode) {
error(errorNode, Diagnostics.Property_0_is_private_and_only_accessible_within_class_1, symbolToString(prop), typeToString(getDeclaringClass(prop)!));
}
return false;
}
return true;
}There was a problem hiding this comment.
Why don't we just do this check unconditionally at the top? It sure seems like the result of this code is that "you can access any property of the current class as long as you're within that class", such that we don't need to do all of this runaround.
Andarist
force-pushed
the
fix/protected-members-within-class
branch
from
71bbed7 to
f00d00b
Compare
|
@typescript-bot test it |
|
In a way this feels wrong; I remember on my first checker bugfix that we didn't want to let one spread out private props which feels similar: #47078 (comment) But, allowing private and not protected seems the oddest of all. |
|
Hey @jakebailey, the results of running the DT tests are ready. Everything looks the same! |
|
Honestly, I don't really know what are the expectations around private/protected when it comes to closures etc. Private properties are allowed in those positions quite explicitly by the code (and IIRC there are tests for it) so this merely matches the behavior of protected properties with that. I don't feel anything in the linked comment says strongly this might be wrong:
Those references to this class here are within the class ;p I feel like the linked comment is mainly about object types created by spreads than about other cases like this here. |
|
@jakebailey Here are the results of running the user tests with tsc comparing Everything looks good! |
|
@jakebailey Here they are:
tscComparison Report - baseline..pr
System info unknown
Hosts
Scenarios
Developer Information: |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
@jakebailey Here are the results of running the top 400 repos with tsc comparing Everything looks good! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #59989