> On Jun 9, 2016, at 07:35, L. Mihalkovic <[email protected]> wrote: > > > On Jun 9, 2016, at 3:27 AM, Jordan Rose via swift-evolution > <[email protected] <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
