R.merge is not compatible with interfaces

[sluukkonen]

This code

import * as R from 'ramda'

interface User {
  readonly name: string
  readonly age: number
}

const u1: User = {name: 'John', age: 25}
const u2: User = {name: 'Jane', age: 25}

const u3 = R.merge(u1, u2)

produces the following error:

Argument of type 'User' is not assignable to parameter of type 'Struct<{}>'.
  Type 'User' is not assignable to type 'ArrayLike<{}>'.
    Property 'length' is missing in type 'User'

I'm not quite sure what's wrong with the "obvious" signature (merge<T1, T2>(a: T1, b: T2): T1 & T2), but the current one is definitely problematic.

[KiaraGrouwstra]

Yeah, this is a variant of our biggest problem right now (e.g. #78), caused by the state of TS; progress for a solution can be found here.

[wclr]

1. What is really wrong with a signature in case of merge?
   merge<T1, T2>(a: T1, b: T2): T1 & T2;?

2. Or why not, if want to introduce constraints that it is a structure:
   merge<T1 extends Struct<any> , T2 extends Struct<any>>(a: T1, b: T2): T1 & T2;

3. Why type Struct<T> = Obj<T> | List<T>; is used when ramda's merge actually expects objects (Obj)?

[KiaraGrouwstra]

Sorry, you're right this signature contained more generics than it could really put to good use.

I guess technically Ramda also accepts the use-case of merging arrays, though I'll admit it's a bit unexpected there it's still going to treat everything as objects anyway:

R.merge([1],[2,3]);
Object {0: 2, 1: 3}

My initial instinct has been to not immediately prohibit use-cases that could technically be legitimate. That said, I'll admit I haven't actually used this array version here myself either...