[Swift-devel] Standard library

[Tim Armstrong]

You can use a positional implementation for sure as long as the caller
knows the argument names of the function it's calling at compile time.
You can't reduce it to the problem of resolving overloads for functions
with purely positional arguments though, since that would require there
being a single consistent mapping of <argument name> -> <argument position>
across all of the overloaded ones.

 You could have it try all of the overloads individually and see which ones
matched, but by that point I think it's too complicated to be worth it.

It would also have the downside that it's harder to work out if two
overloads are potentially ambiguous at the function declaration site (it's
not too bad at the call site - if you have more than one match, it's
ambiguous).  E.g. if I defined  f(float x=0.0, int y=0) and someone writes
code with a call to f(y=0);  Now, if I added another overload f(int y=0),
presumably the compiler wouldn't detect the overloads as ambiguous, since
most ways of calling either are not, but then the call f(y=0) would break,
since it's now ambiguous.  Not great for modularity.

I guess this got into a pretty academic discussion, but I do feel like
keyword arguments and overloading don't play nicely together, and I do
remember someone requesting keyword arguments at one point.


With polymorphism, what do you mean by polymorphism though?  I'd think of
option types and type variables as one form of polymorphism among many, and
probably the most natural one for a statically typed functional language.

It comes up naturally - if you have a function like contains(array,
array_element), then the type really should require that the arguments have
types T[] and T.  The alternatives were to either special-case it in the
compile (not supporting it for user-defined functions and forcing compiler
changes for every addition operator), or by just giving on typechecking and
letting the caller pass in anything as long as the first argument is an
array.

The first would have been workable, but a bit limiting, and the second
would have opened up a can of worms, since then it's possible to compare
variables of completely different types and you have to work out what the
equality rules are.  E.g., what does contains([1.0, 2.0], 1) do?

Anyway, with the avg([]) thing, my point was that the more features, the
more corner cases come up.  Rejecting anything ambiguous is mostly the
right thing to do I think.  In Swift/T it actually gets resolved to an
int[], for the same reason that int A[]; A = []; passes type-checking - the
expression [] has a wildcard in the type: *[].

On Sat, Jan 10, 2015 at 11:40 PM, Mihael Hategan <hategan at mcs.anl.gov>
wrote:

> On Sat, 2015-01-10 at 22:57 -0600, Tim Armstrong wrote:
> > > Am I missing something?
> > >
> > I think the problem I was thinking of is the combination of function
> > overloading and keyword arguments - then you have a number of possible
> > function signatures that grows exponentially with the number of optional
> > arguments.  It's not so bad if it's purely positional arguments since
> then
> > you can just treat a function with n optional arguments as n + 1
> overloads
> > of the function.
>
> I'm not sure. You should be able to statically determine which keyword
> arguments are passed in a given call, fill the missing ones with nulls
> or default values, sort, and generate a call to a single purely
> positional underlying implementation.
>
> >
> > It might take a bit of implementation work to get to work with the other
> > function type checking logic in Swift/T, but it seems tractable.  It's
> > already a bit complicated trying to work out the input types of the
> > function arguments when there's the possibility of type variables, option
> > types, etc.
>
> Shouldn't polymorphism come before fancy type stuff? :)
>
> >
> > There are some weird corner cases.  For example, which implementation of
> > avg would this call?
> > avg([]);
>
> Unless there is some mechanism that can ensure that it doesn't matter,
> or a mechanism allowing you to overload based on specific values (like
> pattern matching), then you probably have to have a way to say exactly
> which function should be called. Java requires you to do an explicit
> cast of arguments that would otherwise result in ambiguity.
>
> Mihael
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150111/3010f4ac/attachment.html>