[Swift-devel] Standard library

[Mihael Hategan]

On Sun, 2015-01-11 at 21:48 -0600, Tim Armstrong wrote:
> 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.

I see what you are saying. I didn't think that far. 

> 
>  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.

Matching seems reasonable though. You have to do the matching anyway as
part of type checking.

> 
> 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.

There is the potential of ambiguous calls if the positional types are
identical and there is an overlap between keyword args. In your case
both lack positionals and both have an int y. That assuming no
subtyping. The overlap part is slightly more difficult than the direct
match. But it can reasonably be detected with defined functions.

> 
> 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.
> 

I think there's an enhancement request in bugzilla for overloading. I
don't know..., I mean yeah, this is pretty academic, but the question
about whether we will support overloading needs to be answered if we are
to come up with a decent common standard library that won't be a moving
target. Well, it's a matter of consistency in K, since run-time
overloading in library functions is supported.

> 
> With polymorphism, what do you mean by polymorphism though?

Right there I meant just function overloading. Sorry.

>   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?

That still compiles in Java actually, even with generics. But then Java
nailed the equality rules part fairly well.

[...]

Mihael