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

[L. Mihalkovic]

> On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi, Paulo. Thanks for bringing this up; it’s definitely an interesting problem to solve.
> 
> My thoughts are mostly in line with yours, that disambiguation at the call site is the most Swift-like thing to do, at least as a first step. Maybe we can add some way to record general preferences, or maybe just asking people to define a wrapper function to put the disambiguation in one place is fine.
> 
> I’m not particularly a fan of the “from” syntax or the “@“ syntax, but I don’t have anything better. (And the “not a fan” is entirely a taste thing, plus a general desire not to steal new keywords or operator characters. Neither of these are blockers.) I’ve been playing with silly things like this:
> 
> str.(ModuleA.capitalized)()
> 

Seeing all these proposals that people make, it makes me thinks that extensions as they exist are not fully understood... People seem to consider them  like the Xtext/Xtend/c# extension METHODS, which means that maybe they should also be added to Swift, and people would not be confused:

public static func capitalized(self:String)() {}    

Then these would be easily individually imported from module x,y or z with the current syntax, and then "extension String {}" would retain it current scoping behavior

No matter what, I think many extensions are just a bad outlook on OOD, but properly understood, they are great.

> which I think has come up on-thread already. (It’s close to Paul’s '::', anyway.)
> 
> A bonus is if we can use this same thing for globals. We have a problem today where “Foo.Bar” can’t refer to a member of a module if there’s also a type named “Foo”; changing the syntax to “Foo::Bar” or “Bar from Foo” (or adding it as an alternative) would solve that problem and provide consistency.
> 
> Sorry I don’t have anything too conclusive to add. My last point is that while we do have a problem today, it’s a problem we’ve lived with for two years, and any features we add to solve it are additive. That means it’s okay if we don’t come up with an answer in Swift 3.
> 
> Jordan
> 
> 
>> On Jun 6, 2016, at 06:47, Paulo Faria via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Actually I don’t like the prioritization of the modules import. I’m much more in favor of disambiguating at call site. like we have to do in any other case of ambiguity in Swift. The concept of precedence is only present in operators and that makes sense because it’s in their nature. I think #4 or #5 or any other way to disambiguate at call site would be the most appropriate.
>> 
>> 
>> 
>>> On Jun 4, 2016, at 10:29 PM, Paulo Faria <paulo at zewo.io> 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
> 
> _______________________________________________
> 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/20160609/05614338/attachment.html>