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 > <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
