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

[L. Mihalkovic]

IMO you have identified some of the symptoms of a larger issue with Swift. 

Currently swift lets us group our code into modules. Within a module we can use folders to physically group the files, but this is not mandatory (and xcode does not by default align the logical and physical structure of a project). My observation of most github projects i read is that people struggle to organize the code, often resorting to adopting a black-socks with black-socks approach (extensions together, structs together...).

The result is that swift is great for small apps or libraries, but not so much for large amounts of code written by several people, when compared to what can be done with scala, java, c++, c#, kotlin, and even typescript. 

Rather than the proposed solution, I would much rather see swift acquire sub-scoping inside modules (call it sub module or namespace) with local imports. I think addressing the symptomes by prioritizing imports will only make it easier to write more disorganized code.


> On Jun 5, 2016, at 3:29 AM, 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/20160605/ab076ba9/attachment.html>