>> I want to discuss the problem of name ambiguity when a computed property or >> function is defined with the same name and type in different modules. >> Currently there’s no way to disambiguate the implementation in use cases >> similar to the one contained in the gist below. >> >> https://gist.github.com/paulofaria/f48d0b847a0fb7c125d163d0e349500a >> >> The gist also contains some informal proposals. The idea is to create a >> formal proposal based on the discussion that shall follow. > > We already have the concept of prefixing a type name with a module to > disambiguate when two modules have the same type. I wonder if we could do the > same thing to disambiguate between conflicting extensions? > > import ModuleA > import ModuleB > > ("hello world" as ModuleA.String).capitalized() // Swift.String, with > only APIs known to ModuleA > ("hello world" as ModuleB.String).capitalized() // Swift.String, with > only APIs known to ModuleB > "hello world".capitalized() // Still causes a > compile-time error for ambiguity >
That is one furious rewrite of the compiler/runtime (module loader, compliance table storage/dynamic resolution ... ), starting with the fact that extensions do not have scopes and are not even types > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
