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

[L. Mihalkovic]

C# has scoped imports to deal with this. I like it... (I went back to c# until swift 3 or 4 get more feature complete).

Regards
(From mobile)

> 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)()
> 
> 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/f4fd564c/attachment.html>