<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>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).<br><br><div>Regards</div>(From<span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); "> mobile)</span></div><div><br>On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Hi, Paulo. Thanks for bringing this up; it’s definitely an interesting problem to solve.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">str.(ModuleA.capitalized)()</div></blockquote><div class=""><br class=""></div>which I think has come up on-thread already. (It’s close to Paul’s '::', anyway.)<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Jordan<br class=""><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 6, 2016, at 06:47, Paulo Faria via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 4, 2016, at 10:29 PM, Paulo Faria <<a href="mailto:paulo@zewo.io" class="">paulo@zewo.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hello, everyone.<br class=""><br class="">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.<br class=""><br class=""><a href="https://gist.github.com/paulofaria/f48d0b847a0fb7c125d163d0e349500a" class="">https://gist.github.com/paulofaria/f48d0b847a0fb7c125d163d0e349500a</a><br class=""><br class="">The gist also contains some informal proposals. The idea is to create a formal proposal based on the discussion that shall follow.<br class=""><br class="">Cheers, <br class="">Paulo</div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>