Too much of "any"

Don’t you think that there are too much of “any” type used through out the definitions, or maybe I am missing something. Consider for example these definitions:

pair(fst: any, snd: any): any[];
insert(index: number, elt: any, list: any[]): any[];
assoc(prop: string, val: any, obj: any): any;
clone(value: any): any;
// there are probably more, these are just found by a quick look

While we still can have them for the cases we don’t have a strict definitions for input/output, I still believe that main point is to squeeze out as much of type safety as we can from Typescript. So don’t you think we should have a generically typed definitions as much as possible for every function? For above examples it might look like this:

pair<F, S>(fst: F, snd: S): [F, S];
insert<T>(index: number, elt: T, list: T[]): T[];
assoc<T>(prop: string, val: any, obj: T): T;
clone<T>(value: T): T;

What do you think?

[donnut]

I agree with you in general that we should try to make the type checking as strict as feasible. Your proposal for the pair function is fine. The insert function is less obvious. The example function of Ramda fails in case of the more strict checking:

R.insert(2, 'x', [1,2,3,4]); //=> [1,2,'x',3,4]

Typescript can not infer type T from the definition as string conflicts with the list of numbers. It is a bit of an awkward example as it mainly shows that you can do weird things with javascript. So I would be in favor of the more strict approach and 1) correct the examples in the test file and 2) except that there will be some clashes in user’s code where the ‘freedom’ of javascript is exploit which is in conflict with the more strict typing.

To be honest, up to now I haven’t made a clear choice, but maybe now it is a good moment to do so. Any more thoughts/ideas on this issue?

[ivan-kleshnin]

@yazla I believe TS can’t express an “array of single generic type”. That’s because JS has no tuples and you can’t disallow array of mixed types by default because it will disable tuples.