-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Update for fileprivate
#410
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
Conversation
👏 |
@@ -268,19 +268,19 @@ private class LocalFS: FSProxy { | |||
// | |||
// FIXME: This class does not yet support concurrent mutation safely. | |||
public class PseudoFS: FSProxy { | |||
private class Node { | |||
fileprivate class Node { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This surprises me, it is certainly the intent that this is private
not fileprivate
. What required this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember thinking that too. Probably a bogus diagnostic at one point. I'll change it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I remember now. The rule here is the inner scope can refer to private
members in the outer scope but not vice-versa. PseudoFS
is using Node
's members quite a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Huh, this seems unfortunate for exactly this use case. Declaring it as fileprivate looks wrong... is it possible this indicates a problem in the proposal?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does seem wrong to use file
to mean scope
especially considering the name of the proposal itself, but it was the name the community settled on 😅
|
I would also like to add that the migration path provided by @CodaFi is the correct automated migration - It is probably reasonable to discuss whether this moves forward first as a semantic-preserving migration and then Swift PM does a review to tighten visibility, or whether that review should be part of the initial migration. |
Thanks for the clarification @anandabits, that is a relief -- I do strongly prefer the interpretation you are espousing. |
We need to not do this kind of clarification here. Let's get this in writing on SE-0025 before any of this goes through. This patch may need to be amended soon anyhow. |
I was just referring to the reference to the thread... I can't keep up with all the lists so I appreciate pointers when useful. I agree official discussion/decisions needs to be on the list. |
Closing per #476 |
[BuildSystem] Handle relative paths in 'shell' makefile-style dependencies
Implements the access control changes needed for the Swift Package Manager to compile under swiftlang/swift#3000.