[swift-evolution] Name disambiguation of computed property/function with same type defined in extensions
Thorsten Seitz
tseitz42 at icloud.com
Wed Jun 8 14:02:33 CDT 2016
> Am 07.06.2016 um 22:27 schrieb L Mihalkovic <laurent.mihalkovic at gmail.com>:
>
>>
>> On Jun 7, 2016, at 9:47 PM, Thorsten Seitz <tseitz42 at icloud.com <mailto:tseitz42 at icloud.com>> wrote:
>>
>>
>>
>> Am 07.06.2016 um 20:11 schrieb L Mihalkovic via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>>
>>> T1 =======
>>> import Lib1
>>> var str = func2() // lib1
>>>
>>> T2 =======
>>> import Lib1
>>> import func Lib2.func2
>>> var str = func2() // lib2
>>
>> Shouldn't func2() be ambiguous here? It is imported from Lib1 and from Lib2.
>>
>> -Thorsten
>
>
> no, that is precisely the point .. it works!! I am able to override whatever my laziness brought into scope from Lib1 (caused by my * import) with a meticulously chosen implementation from Lib2. It is brilliant. extensions on the other hand work differently (although something could undoubtedly be done about them, I cannot entirely convince myself that it is time well spent. It would be if that could be a stepping stone form something else (which I have not been able to identify so far).
So it is dependent on the order of the imports? That’s rather fragile IMO and I would prefer having to solve clashes explicitly independent of import order, e.g. by having to hide the version from Lib1:
import Lib1 hiding func2 // strawman syntax
import func Lib2.func2
-Thorsten
>
>
>>>
>>> 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 <cantrell at pobox.com <mailto:cantrell at pobox.com>> wrote:
>>>>
>>>>>
>>>>> On Jun 7, 2016, at 11:36 AM, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>
>>>>>>
>>>>>> On Jun 7, 2016, at 10:47 AM, L. Mihalkovic via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>
>>>>>> On Jun 7, 2016, at 4:53 PM, Tony Allevato <allevato at google.com <mailto:allevato at 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 at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/374c4e20/attachment.html>
More information about the swift-evolution
mailing list