You forgot one :-) let capitalizedA = ModuleA { "hello swift".capitalized() }
+1 on finding a way to explicitly resolve naming collisions. I'm generally in favor of something like #2 (or #3). A while back, there was a proposal to replace numerical operator precedence with a relative precedence system. I can't remember if it went through, but if so I would argue that the two systems should probably be the same, since they solve the same problem. I would also suggest there be a way to import a module at a lower precedence than the current source file, for the purposes of "overriding" any top-level functions (or even types, I suppose). Something like "partially import ModuleA" would solve the problem as well, but I can't think of anything resembling a practical syntax for specifying which parts. - Dave Sweeris > On Jun 4, 2016, at 20:29, Paulo Faria via swift-evolution > <swift-evolution@swift.org> wrote: > > Hello, everyone. > > 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. > > Cheers, > Paulo > _______________________________________________ > 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