[Swift-devel] Reconsidering function overloading

[Tim Armstrong]

Mike - that's technically possible to implement but I don't see the
cost/benefit stacking up that well - I think any new syntactic constructs
come with a non-neglible implementation/documentation/user attention cost
that can quickly accumulate if we're not selective about what we put into
the language (see C++).  Tangentially, that particular syntax is difficult
to parse unambiguously - you could be trying to index a variable called int
and pass it into max.

The problem I see with #3 is that we're allowing overloaded functions so
that the standard library seems slightly neater/more friendly.  If that
results in a bunch of exceptions where users can't do something that "ought
to" work - composing two standard library functions reduce/max, I just
don't see enough of a net benefit (if any) to the programmer experience to
justify the implementation burden.

This of course is somewhat subjective - I tend to like languages where
there is a simple and consistent but powerful set of core rules that are
orthogonal and compose well together - you can learn the basic rules and
don't have to worry about many exceptions.  Other language designs will
special-case common constructs so that use-cases that the language designer
expects to be common will be shorter or "cuter", or add features that don't
compose well with other features and come with caveats/exceptions.  I think
C, Haskell and Python are examples of the former, and Perl, R and C++ are
examples of the latter.  I'm not sure which camp we see ourselves in.

I haven't found complete documentation on Apple Swift's type inference, but
it doesn't seem like it does anything very sophisticated - Swift/T already
does similar local type inference.

- Tim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150128/f363671c/attachment.html>