[Swift-devel] Reconsidering function overloading

[Tim Armstrong]

I agree the overloaded functions provide some nice functionality - I find
it frustrating in C that there's no built-in min/max, for example.  I don't
like minInt/minFloat/etc, but they may be the lesser evil.

I'm not sure how strcat is implemented in Swift/K. In Swift/T there is a
single function prototype, but the arguments are option types -
string|int|float.  This avoids the issue of working out which version of
strcat was meant, since there is only one version that accepts multiple
argument types - the compiler doesn't need to inspect the argument types to
work out which strcat you meant.

There are two things I think you might mean by a var type.  The first is
static typing where you can omit the variable type and have the compiler
infer it based on the right hand side of the assignment.  Swift/T actually
already supports this in some cases.  The other option is dynamic typing
where the type of the variable may vary at runtime.  The problem here is
that you generally then need runtime introspection to work out the type of
the variable so you know what to do with it.  It also prevents some
typechecking.

Varargs is also in the mix - we do support it already.  I think it could
work ok with overloading from the point of view of user experience, but I'd
probably avoid supporting overloading of varargs functions since the use
cases seem limited and the implementation would be some work.

I'm still thinking through overloading and if there's a better way to
implement it than the way I was originally thinking of.  I'm looking at the
typechecking code and it might be a little easier than I thought if I
approach it in the right way.

- Tim

On Wed, Jan 28, 2015 at 9:14 AM, Michael Wilde <wilde at anl.gov> wrote:

>  Based on your point here and earlier, Tim, I agree with going with option
> #1. So count this as a +1 for that.
>
> Function references give us something we can not otherwise do, while
> overloaded functions is just a convenience (which not everyone will like).
>
> How does this apply to intrinsic functions in the library, though, eg,
> strcat( ) which you could view as an overloaded function?
>
> Can we address this more cleanly by introducing a type "var"? (I can't
> recall where we left prior discussion on that issue).  Also, are we dipping
> into the tangentially related issue of var-args (varying number of args)
> here?
>
> - Mike
>
> ps. I prefer the approach of "simple and consistent but powerful set of
> core rules that are orthogonal and compose well together" in the C,
> Haskell, Python vein.
>
>
>
> On 1/28/15 9:01 AM, Tim Armstrong wrote:
>
>  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
>
>
> --
> Michael Wilde
> Mathematics and Computer Science          Computation Institute
> Argonne National Laboratory               The University of Chicago
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150128/726221d7/attachment.html>