[swift-dev] A type-checking performance case study

[Joe Groff]

> On Apr 11, 2016, at 8:40 AM, John McCall <rjmccall at apple.com> wrote:
> 
>> On Apr 11, 2016, at 8:35 AM, Joe Groff <jgroff at apple.com> wrote:
>>> On Apr 8, 2016, at 11:47 AM, John McCall via swift-dev <swift-dev at 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