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
Currently, the NoAccessLevelOnExtensionDeclaration rule removes access level attributes from all extensions, regardless of the specific access level. However, there is a valid use case for allowing private and fileprivate extensions while disallowing public extensions.
When an extension is marked as private or fileprivate, it provides a clear indication that the extension and its members are not intended to be accessed from outside the current file or declaration scope. This can help prevent unintended leakage of implementation details and maintain encapsulation.
On the other hand, public extensions can be a source of unintended behavior and may not always align with the intended visibility of the extension members.
func testDisallowPublicExtension(){assertFormatting(
NewRule???.self,
input:""" public extension Foo { var bar: String { "" } } private extension Foo { var baz: String { "" } }""",
expected:""" extension Foo { public var bar: String { "" } } private extension Foo { var baz: String { "" } }""",
findings:[// TODO: Add findings])}
It may be worth considering allowing users to have more customization options and define which access levels should be moved and which should not. This would provide more flexibility and cater to different project requirements and coding styles.
It seems reasonable to add a configuration setting for this.
Rather than focusing on public specifically, I wonder if we should draw the line between access levels that are visible outside the module vs. access levels visible only inside? In other words, ban public/package extension but allow internal/fileprivate/private extension.
Currently, the
NoAccessLevelOnExtensionDeclaration
rule removes access level attributes from all extensions, regardless of the specific access level. However, there is a valid use case for allowingprivate
andfileprivate
extensions while disallowingpublic
extensions.When an extension is marked as
private
orfileprivate
, it provides a clear indication that the extension and its members are not intended to be accessed from outside the current file or declaration scope. This can help prevent unintended leakage of implementation details and maintain encapsulation.On the other hand,
public
extensions can be a source of unintended behavior and may not always align with the intended visibility of the extension members.Originated from: swiftlang/swift-syntax#2602 (comment)
The text was updated successfully, but these errors were encountered: