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] >> <mailto:[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 >> <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
