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