[Swift-devel] Standard library

[Mihael Hategan]

On Mon, 2015-01-12 at 11:45 -0600, Tim Armstrong wrote:
> 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 think rejecting such cases is fine. With or without overloading
+keyword args, such pairs of functions wouldn't be allowed. But with
overloading+keyword args, there is more flexibility and certain things
can be written more elegantly than without. So overloading adds things
and doesn't prevent any of the things that are possible without.

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

Right. This makes sense under the assumption that you can nicely deal
with ambiguity. I believe it's possible and not terribly difficult, but
it's just a hunch.

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

Ok. Let's start there. For the purpose of a common standard library,
that's all we need. We can later look into the feasibility of also doing
this for user-defined functions.

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

I like type variables. I'm not arguing against them. Just that in my
head, they were a step or two up the ladder of fanciness from function
overloading.

> 
> 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 a mixed blessing. It gives flexibility of defining equality classes
across different types, but that is rarely used IMO. As you say though,
that is probably an accidental feature.

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

Right. It's not an easy problem. Comparable<T> solves some of that, but
not much.

Mihael