> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> On Jun 7, 2016, at 4:53 PM, Tony Allevato <allev...@google.com
> <mailto:allev...@google.com>> 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.
IIRC, a member of the core team (Joe Groff, maybe?) indicated several months
ago on the list that methods are internally namespaced to their module. Alas, I
can’t find that message. It was a long time ago.
You can see this in the fact that two different files can see two different
extension methods:
A.swift
import ModuleA
…
"hello world".capitalized()
B.swift
import ModuleB
…
"hello world".capitalized()
…even if they end up compiled into the same binary. And that makes sense:
A.swift only expected to see ModuleA’s extension, and was presumably coded
around that expectation. That ModuleB happened to end up mixed into the same
binary shouldn’t change the behavior of A.swift
If my understand is correct, then my "hello world”.ModuleA::capitalized() and
your "hello world".(capitalized from ModuleA)() are both just syntax to expose
something that Swift already tracks internally.
Cheers, P
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
