I like the "from" keyword the best, but I'll take my own stab at a
modification:
import ModuleA
import ModuleB
"hello world".(capitalized from ModuleA)()
"hello world".(capitalized from ModuleB)()
"hello world".(someProperty from ModuleA)
"hello world".(someProperty from ModuleB)
The "from" keyword makes it clearer than arbitrary punctuation what's going
on, and extending the member reference syntax to support ".(member from
Module)" seems clearer than putting the "from Module" after the actual
call; we're saying "look up the member named 'member' on the receiver's
type inside Module", as opposed to having it look like the "from" applies
to the *expression*, which it doesn't.
Having the parens there is helpful in the property disambiguating case,
where we would otherwise have this:
"hello world".someProperty from ModuleB.bar
Is that a property "bar" on the result of "someProperty" from ModuleB, or
is that "someProperty" from submodule ModuleB.bar? This removes the
ambiguity:
"hello world".(someProperty from ModuleB).bar
On Tue, Jun 7, 2016 at 7:27 AM LM via swift-evolution <
swift-evolution@swift.org> wrote:
>
>
> >> We already have the concept of prefixing a type name with a module to
> disambiguate when two modules have the same type. I wonder if we could do
> the same thing to disambiguate between conflicting extensions?
> >>
> >> import ModuleA
> >> import ModuleB
> >>
> >> ("hello world" as ModuleA.String).capitalized() // Swift.String,
> with only APIs known to ModuleA
> >> ("hello world" as ModuleB.String).capitalized() // Swift.String,
> with only APIs known to ModuleB
> >> "hello world".capitalized() // Still causes a
> compile-time error for ambiguity
> >
> > This only introduces a new kind of ambiguity since you can have both
> ModuleA and ModuleB declare something like
> >
> > class String {
> > /// ...
> > }
> >
> > And now you have no idea if ModuleA.String refers to Swift.String
> extension in ModuleA or class String in ModuleA.
> >
>
> Keep in mind that extensions are not types. (See prev response)
>
> >
> >
> >>
> >> --
> >> Brent Royal-Gordon
> >> Architechies
> >>
> >> _______________________________________________
> >> swift-evolution mailing list
> >> swift-evolution@swift.org
> >> https://lists.swift.org/mailman/listinfo/swift-evolution
> >
> > _______________________________________________
> > swift-evolution mailing list
> > swift-evolution@swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
