You forgot one :-)
let capitalizedA = ModuleA {
"hello swift".capitalized()
}
+1 on finding a way to explicitly resolve naming collisions. I'm generally in
favor of something like #2 (or #3). A while back, there was a proposal to
replace numerical operator precedence with a relative precedence system. I
can't remember if it went through, but if so I would argue that the two systems
should probably be the same, since they solve the same problem.
I would also suggest there be a way to import a module at a lower precedence
than the current source file, for the purposes of "overriding" any top-level
functions (or even types, I suppose).
Something like "partially import ModuleA" would solve the problem as well, but
I can't think of anything resembling a practical syntax for specifying which
parts.
- Dave Sweeris
> On Jun 4, 2016, at 20:29, Paulo Faria via swift-evolution
> <[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
