[swift-evolution] Name disambiguation of computed property/function with same type defined in extensions

Jordan Rose jordan_rose at apple.com
Thu Jun 9 12:04:43 CDT 2016


> On Jun 9, 2016, at 07:35, L. Mihalkovic <laurent.mihalkovic at gmail.com> wrote:
> 
> 
> On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> 
>> Hi, Paulo. Thanks for bringing this up; it’s definitely an interesting problem to solve.
>> 
>> My thoughts are mostly in line with yours, that disambiguation at the call site is the most Swift-like thing to do, at least as a first step. Maybe we can add some way to record general preferences, or maybe just asking people to define a wrapper function to put the disambiguation in one place is fine.
>> 
>> I’m not particularly a fan of the “from” syntax or the “@“ syntax, but I don’t have anything better. (And the “not a fan” is entirely a taste thing, plus a general desire not to steal new keywords or operator characters. Neither of these are blockers.) I’ve been playing with silly things like this:
>> 
>> str.(ModuleA.capitalized)()
>> 
> 
> Seeing all these proposals that people make, it makes me thinks that extensions as they exist are not fully understood... People seem to consider them  like the Xtext/Xtend/c# extension METHODS, which means that maybe they should also be added to Swift, and people would not be confused:
> 
> public static func capitalized(self:String)() {}    
> 
> Then these would be easily individually imported from module x,y or z with the current syntax, and then "extension String {}" would retain it current scoping behavior
> 
> No matter what, I think many extensions are just a bad outlook on OOD, but properly understood, they are great.

I’m not sure what you mean. How does changing the declaration site solve the disambiguation problem at the call site? (And how do you think Swift extensions differ from C# extensions?)

Jordan

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160609/5056049b/attachment.html>


More information about the swift-evolution mailing list