and as you would expect …
T4 =======
import Lib1 // importing EVERYTHING from lib1
import func Lib2.func2 // importing ONLY func2 from lib2
var int1 = func1() // 1 , because lib2::func2 is not ‘visible'
—> showing again how extensions are treated differently
Lib1 ===========
public func func1() -> Int {
return 1
}
Lib2 ===========
public func func1() -> Int {
return 2
}
from what I saw and read, this is a rather fundamental behavior that may not be
easily negotiated.
> On Jun 7, 2016, at 8:11 PM, L Mihalkovic <laurent.mihalko...@gmail.com> wrote:
>
> T1 =======
> import Lib1
> var str = func2() // lib1
>
> T2 =======
> import Lib1
> import func Lib2.func2
> var str = func2() // lib2
>
> T3 =======
> import Lib1
> import func Lib2.func2
> var str = “str”.allCaps() // ERROR : ambiguous name
>
>
> Lib1 ===========
> public func func2() -> String {
> return "lib1"
> }
> // only during T3
> public extension String {
> public func allCaps() -> String {
> return “lib1_"
> }
> }
>
> Lib2 ===========
> public func func2() -> String {
> return "lib2"
> }
> // only during T3
> public extension String {
> public func allCaps() -> String {
> return "lib2_"
> }
> }
>
>
> T3 shows how differently extensions are treated from all other
> exportable/importable artifacts: extensions are NOT sensitive to the scope
> of imports. they are fully loaded as soon as the loader detects that the
> module is referenced (they come from their own table inside the module
> binary).
>
>
>
>
>> On Jun 7, 2016, at 6:45 PM, Paul Cantrell <cantr...@pobox.com
>> <mailto:cantr...@pobox.com>> wrote:
>>
>>>
>>> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution
>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>
>>>>
>>>> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution
>>>> <swift-evolution@swift.org <mailto: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.
>>
>> Ah, here it is:
>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000928.html
>>
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/000928.html>
>>
>> Joe Groff wrote:
>>
>> “It's helpful to think of method names as being namespaced in Swift, by both
>> their enclosing module and type. If two modules independently extend a
>> protocol with a method of the same name, you still semantically have two
>> distinct methods that dispatch independently. The extension would have to be
>> factored into a common module both modules see for them to interact.”
>>
>> IOW, yes, Swift internally does something very much like "hello
>> world”.ModuleA::capitalized().
>>
>>> 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 <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
