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
If a protocol conformance is imported into one file of a module, that conformance leaks into other files of the same module. That leaky behavior violates the rule that the visibility of an import is confined to the file in which the import is stated.
// Module ApublicstructX {
publicletvalue: Intpublicinit(_value: Int) { self.value = value }
}
// Module BimportAextensionX: Equatable {
publicstaticfunc ==(lhs: X, rhs: X) -> Bool { lhs.value == rhs.value }
}
// Module C - FileOne.swiftimportAimportBpublicfuncfirst() { print(X(1) == X(1)) }
// This compiles because Equatable conformance// is imported from A.// Module C - FileTwo.swiftimportApublicfuncsecond() { print(X(1) == X(2)) }
// This should not compile because conformance // to Equatable is not declared.// But, it does compile because the Equatable // conformance imported in FileOne somehow is // visible in FileTwo.
This issue leads to other seemingly incorrect behavior.
(A) INDETERMINATE DISPATCH. If multiple conflicting conformances are imported into FileOne (e.g., one from Module A and another from some other module), then, in FileTwo, if the protocol requirement is accessed, the compiler seems to pick one of the conflicting conformances. It is not clear how the compiler chooses which to call.
(B) INABILITY TO DECLARE CONFORMANCE. If a conformance is imported into FileOne, then, in FileTwo, it is not possible to declare a different version of the conformance for use within Module B. The compiler raises a redundancy error, and points at the conformance provided by A.Array<Int>.
NOTE: I cannot find formal documentation of the rule-of-import-visibility to which I refer. That inability to find documentation may be due to a lack of diligence on my part or a documentation bug. Alternatively, that inability may be evidence that the rule does not actually exist. If the rule does not exist, then, I believe Swift needs a formal rule to govern the scope of import visibility.
The text was updated successfully, but these errors were encountered:
Additional Detail from JIRA
md5: 27233772a9be23a732852d1bad7b6b18
Issue Description:
If a protocol conformance is imported into one file of a module, that conformance leaks into other files of the same module. That leaky behavior violates the rule that the visibility of an import is confined to the file in which the import is stated.
This issue leads to other seemingly incorrect behavior.
(A) INDETERMINATE DISPATCH. If multiple conflicting conformances are imported into FileOne (e.g., one from Module A and another from some other module), then, in FileTwo, if the protocol requirement is accessed, the compiler seems to pick one of the conflicting conformances. It is not clear how the compiler chooses which to call.
(B) INABILITY TO DECLARE CONFORMANCE. If a conformance is imported into FileOne, then, in FileTwo, it is not possible to declare a different version of the conformance for use within Module B. The compiler raises a redundancy error, and points at the conformance provided by A.Array<Int>.
NOTE: I cannot find formal documentation of the rule-of-import-visibility to which I refer. That inability to find documentation may be due to a lack of diligence on my part or a documentation bug. Alternatively, that inability may be evidence that the rule does not actually exist. If the rule does not exist, then, I believe Swift needs a formal rule to govern the scope of import visibility.
The text was updated successfully, but these errors were encountered: