[Swift-devel] Standard library

[Mihael Hategan]

Inline...

On Sat, 2015-01-10 at 16:57 -0600, Tim Armstrong wrote:
> Nice work.
> 
> I agree, I don't care about the naming convention for functions, so let's
> just pick one and be consistent going forward (we can keep old names
> around, at least forsome amount of time).  I'm also of the opinion that we
> should avoid strcat and other c-inspired names since they don't fit the
> naming convention and probably are only familiar for a minority of users.

I agree on strcat, etc.

> 
> We do support user-defined polymorphic Tcl functions to some extent -
> option types, type variables (e.g. the type signature for contains is <K,
> V> (boolean o) contains(V A[K], K key), and variable length argument
> lists.  We don't pass type information into the function, so if you want
> the function to do something different for each type you can't do that.  My
> understanding is that that's fairly straightforward in Swift/K since the
> function can just look at the Swift type of the Java object it's passed.

You say user-defined and Tcl. Does this mean a user writing Tcl inside a
swift script or that the mechanism to extend swift using Tcl is
documented and generally accessible to users?

And yes, the type is passed to Java. I'd like to change that to proper
compile-time binding. It's not difficult, just not a priority right now.
However, how do avg(int[]) and avg(float[]) work in T?

> 
> The polymorphism is compile-time (the compiler always knows the type of
> each variable and expression).  I'm a little sceptical of using too much
> polymorphism in library functions because it prevents type-checking from
> catching errors.  I think it's fine if the function actually does
> conceptually the same thing for each input type (e.g. converting them to a
> string representation), but it's less of a good idea if it does different
> things (e.g. converting a float to an int and a string to an int are
> different operations).  There's a bit of personal taste to whether you do
> these things, but I think once you allow looser typing rules,it's hard to
> undo that decision.

I agree with what you are saying. I believe that abs/min/max/etc. can be
polymorphic without much danger. I think that length(string) and
length(array) are also reasonable.

But I can see the wisdom in having parseFloat(string) instead of
overloading toFloat(int).

On the other hand, if you wanted to name them more declaratively, they
would probably both sound more like asFloat().

> 
> RE: function overloading. I think we have to choose between
> optional/default arguments and function overloading - I think implementing
> one would preclude the other.

I'm not sure about that. There may be some (non-transitive) ambiguity
between:

f(int a) vs. f(int a, int b = 0) vs. f(int a, int b).

A compiler could complain about the conflict between the middle one and
the rest. But I don't see a problem with:

f(int a), f(float a).

Am I missing something?

Mihael