> 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. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
