[swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

Jordan Rose jordan_rose at apple.com
Wed Jun 8 20:00:00 CDT 2016


> On Jun 7, 2016, at 11:11, L Mihalkovic via swift-evolution <swift-evolution at swift.org> wrote:
> 
> T1 =======
> import Lib1
> var str = func2()	// lib1
> 
> T2 =======
> import Lib1
> import func Lib2.func2
> var str = func2()	// lib2
> 
> T3 =======
> import Lib1
> import func Lib2.func2
> var str = “str”.allCaps()	// ERROR : ambiguous name
> 
> 
> Lib1 ===========
> public func func2() -> String {
>   return "lib1"
> }
> // only during T3
> public extension String {
>   public func allCaps() -> String {
>     return “lib1_"
>   }
> }
> 
> Lib2 ===========
> public func func2() -> String {
>   return "lib2"
> }
> // only during T3
> public extension String {
>   public func allCaps() -> String {
>     return "lib2_"
>   }
> }
> 
> 
> T3 shows how differently extensions are treated from all other exportable/importable artifacts:  extensions are NOT sensitive to the scope of imports. they are fully loaded as soon as the loader detects that the module is referenced (they come from their own table inside the module binary).

I personally consider this a longstanding bug, and would like extension member visibility to follow the same rules as top-level visibility. I don’t think that’s trivial to change, though; the lookup paths are very very different.

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/7b4cd804/attachment.html>


More information about the swift-evolution mailing list