> On Jun 7, 2016, at 4:53 PM, Tony Allevato <[email protected]> wrote: > > 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)
Hmmm... looks like an oxymoron in its own right... I was under the impression so far that the point of extensions was that they are not tied to a source. This brings us back full circle to the very definition of extensions... However you slice it, swift is lacking some scoping bellow modules, and/or arround some of the language features. > > 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 >> <[email protected]> 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 >> >> [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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
