[Swift-devel] Standard library

[Tim Armstrong]

I'm still not sure what you'd do with situationally ambiguous functions
though.

E.g. with the following
f(float x=0.0, int y=0)
f(int y=0)

Neither dominates the other, since f(0.0, 0) and f(0) would get dispatched
to the first and second.  So it's not like it's obviously wrong code that
should be an automatic compile error.  I'm not sure if there is an
algorithm in general to detect partially ambiguous functions (depending on
details of the type system).  If there was you could try to warn or error
on partially ambiguous functions, although providing comprehensible
explanations of the problem might be an issue.

I think supporting overloading only for specific built-ins isn't such a bad
thing (we do that for arithmetic operators, for example).  I think some
users might find it preferable to define overloads f(int) and f(float), but
they can achieve the same effect with fInt(int) and fFloat(float), even if
it's less aesthetically pleasing.

You could say the same for my type variable thing I guess too - just
special case it in the compiler for size() and contains().  Then there
would be a limited number of special additional functions like map(),
reduce(), etc, that could be special-cased.  But there's no way then that
you can achieve the same effect with a finite number of function
definitions - you'd have to have an overload for every possible type, or
just special-case it in the compiler.

Java sort of gives up on typechecking in that case and just calls
.equals(Object).  They didn't really have much of a choice since that was
baked in before they had generics.  It's at least simple enough but it's
definitely made it easier for bugs to go uncaught in STC, for example - I
think there have been at least 15-20 things that I've had to track down
that have boiled down to equals being called on two types that aren't
comparable.

On Sun, Jan 11, 2015 at 11:19 PM, Mihael Hategan <hategan at mcs.anl.gov>
wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/swift-devel/attachments/20150112/9cbd9b67/attachment.html>