> On Apr 11, 2016, at 8:40 AM, John McCall <rjmcc...@apple.com> wrote: > >> On Apr 11, 2016, at 8:35 AM, Joe Groff <jgr...@apple.com> wrote: >>> On Apr 8, 2016, at 11:47 AM, John McCall via swift-dev >>> <swift-dev@swift.org> wrote: >>> >>> One very drastic solution to this problem would be to eliminate >>> non-labelled overloads. (A perhaps more-reasonable way to describe this is >>> to say that argument labels are a part of the name, and therefore two >>> declarations with different labels are not overloads.) That is, given the >>> syntactic form of an expression, we would always be able to find a single >>> function that it could invoke. The current argument-labelling design of >>> the language does make this more palatable than it was in earlier >>> iterations. However, I don't think it's palatable enough: this change >>> would be very limiting, and in particular I think we are very unlikely to >>> accept it for operators or single-argument initializers. >> >> Independent of eliminating overloads, our model has been strongly trending >> toward "labels are part of the name". It seems like a bug to me at this >> point that we consider declarations with different argument labels to be >> overloads in the type checker. Now that we've banned tuple splatting, we >> should be able to enforce argument label matching much earlier in the >> type-checker pipeline, which should prune the overload set a lot for >> initializers and many Cocoa naming conventions. > > I completely agree, and the type-checker does now do this.
Nice. FWIW, your overload-hiding approach makes sense to me. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
