Intersection types with duplicated properties of different types

[teintinu]

interface A {
  p: number
}
interface B {
  p: string
}
type C = A & B; // suggest an error here
var c: C;
c.p = 1; // because it's impossible assign a number or
c.p = "x";  // a string to that property.

[kitsonk]

But some could read this as the resulting type is:

interface C {
  p: number|string;
}

I am not sure of the rules of the intersection types in 1.6 though, but I think there has been a lot of discussion lately that they are more "merge-like" types then strictly "intersection" types, but I believe they are intended to be quite permissive.

[teintinu]

ok @kitsonk , It works well the way it is, my suggestion it's only for better error message.

However number|string it's not the same that number&string. number|string it's possible and very useful whilst number&string it's not possible.

[RyanCavanaugh]

We recognize that intersections between primitives are hard to rationalize, but it's not obvious where or why we would actually issue an error.

Consider some code:

// Can't error here
function merge<T, U>(x: T, y: U): T & U {
    return null; // TODO
}

// Maybe error here?
let y = merge({p: ''}, {p: 32});
// Or here?
let z = y.p;

If we think about some 'bigger' types:

interface A {
    x: number;
    y: string;
}

interface B {
    x: string;
    z: boolean;
}

type C = A & B;

Is C actually a problem? Maybe you only want to use y and z on it. It'd be silly to stop you. For any sufficiently large types, a conflict like this is actually rather likely.

[teintinu]

Thank you @RyanCavanaugh , I understood the point. It's not problem to me, typescript compiler already issues the error on assignment, it's enough.
I'll will close this issue because it's ultra low priority.
Thanks for all!