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

David Sweeris davesweeris at mac.com
Sat Jun 4 22:22:12 CDT 2016

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 at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160604/d2587349/attachment.html>

More information about the swift-evolution mailing list