Repository navigation
Intersection types #1256
Description
Activity
We talked about these during the process of designing unions but didn't prioritize them highly as we didn't see a ton of compelling use cases. If you have some examples that would be helpful. It's certainly doable.
For every function that involves mixins :
function mixins<A,B>(base: { new() :A }, b: B}) : { new(): A & B} Object.assign<A,B>(a: A, b: B): A & B; Object.assign<A,B, C>(a: A, b: B, c: C): A & B & C; // few more overload I guess and it's ok Object.assign<A, B>(a: A, ....B[]): A & B;
Mixins are a good example. We talked about them a bit the other day. I believe we need more than intersection types to model them well though, we specifically talked about what the signature for Object.assign would be, it's more like:
Object.assign<T, ...U[]>(target: T, sources: ...U[]): T & ...U[]
unless we manually write out some number of overloads and just never let you mix in more than x things at a time (which is what your overloads there would do). Perhaps that's an acceptable solution though.
Why could we not do both ? in my example the final overload use rest
The overloads would hopefully be unnecessary if we had 'rest type parameters' but both could be useful. In any case, mixins are definitely a good example for this, but they're also something we will look at holistically beyond just intersection types given the desired use cases (ex considering what's mentioned in #727 and #311). If there are other examples worth considering specifically for intersection types we should make sure to get those on paper too.
Actually I don't see any other case flow use them to declare function overload, not sure it is really helpful, I guess if we search a bit they could be some special edge case but not that I can think of.
I keep finding uses for intersection types in my code (even before I knew flow has them).
A typical example is an injected dependency in a constructor argument that requires an object implementing several interfaces (the combinations are too many to have dedicated interfaces for every combination) for ex.
var x = new Foo(barObject: Countable & Sortable & Serializable);I'd really love to see intersection types in TypeScript.
A stackoverflow request for the same : http://stackoverflow.com/q/27325524/390330
Side note, I think it's important to implements intersection type with an algorithm that take in account that order should matter.
interface A { a: string; c: string; } interface B { b: string; c: number } type AB = A & B // { a: string; b: string: c: number }; type BA = B & A // { a: string; b: string: c: string };
I think it's pretty important
Reacted by Artyom Kohver, Ali Hammad and ViktorFrançois de Campredon (@fdecampredon) Order should matter if one type can override a definition in another.
But another approach could be that types with (incompatible) property collisions can't be intersected (type error).
It's a matter of avoiding accidental errors vs. flexibility. I think the default resolution should be an error for now, with an open possibility in the future to explicitly declare you're ok with the collision (so one should override the other).
Stan Vass (@stanvass) yup valid also
It's notable that
Object.assign,$.extendetc. cannot be usefully described by TS's type system and yet such functions are extremely widely used in real JS code.TS gives great support to classes. But using classes means following a particular pattern where I have to use
this, which can mean a lot of quite radical surgery on thousands of lines of existing JS code. I tried converting a few large modules that way, class-izing them, but it was damn hard work. To avoid that pain as I've adopted TS, I've used$.extendand extra interfaces and casting-I-mean-type-asserting.interface ICar { void accellerate(deltaV: number); } interface ISteerable { steer(direction: number): void; } // Pure intersection of two types! PLEASE DO NOT MODIFY!! interface ISteerableCar extends ICar, ISteerable { }So:
var car = carFactory.makeCar(); var s: ISteerable = { steer(direction) { ... } }; var steerableCar = <ISteerableCar>$.extend(car, s);This pattern is type-safe against changes to both the
ICarandISteerableinterfaces: thesobject literal will fail to compile if I don't keep it up-to-date with changes toISteerable.But it is not safe against independent changes to
ISteerableCar. The type assertion in front of$.extendis based purely on trust that future maintainers will read the comment onISteerableCarand not add methods or further base interfaces.Classes don't have this problem:
class Car { accellerate(deltaV: number) { ... } } class SteerableCar extends Car { steer(direction: number) { ... } }In JS classes are just syntactic sugar: they don't do anything you couldn't do another way. But in TS classes are magic. They conceal a call to an
extendhelper that is strongly typed, which we cannot do ourselves in TS.With intersection types I wouldn't need
ISteerableCarwith a scare-comment. I'd just sayISteerable&ICar. And with a properly typedObject.assign:var sc: ISteerable&ICar = Object.assign(carFactory.makeCar(), { steer(direction: number) { ... } });The great thing about JS is that by providing the tools needed to build objects dynamically, it allows library authors to come up with their own solutions to mixins, multiple-inheritance, aspect-oriented cross-cutting concerns and so on. So I'd love to see TS striving to be the compile-time equivalent of that.
This means that the logical building blocks of type relationships (such as intersection) should be regarded as important in-and-of themselves. They allow the type system to express things that can be done at runtime, and so they support library authors who experiment with ways of building objects.
Yes, classes are the ready-to-wear approach. But give library authors the building blocks so they can try other approaches. This is JS's strength - it's not frozen into one classical OO-style. But at the moment TS is rather class-biased. And lots of JS experts love to hate classes...
And lots of JS experts love to hate classes..
Where's the evidence for that? Perhaps fairer to say "Lots of small (or legacy) library developers"?
For large-scale application development a class-based approach is the only way. In such a framework, object literals represent the data (while classes represent the business logic). It doesn't pay (in terms of memory, performance and maintainability) to dynamically endow object literals with sophisticated logic as proposed in the example above.
(NB: I don't have any objection to implementing this feature: I only point out that there are good reasons for TypeScript to remain biased towards classes.)
Reacted by Patrick LienauReacted by Lasana Murray9 remaining items
I think the order should not matter, it should throw error if one tries to intersect incompatible field types.
If one really wants to intersect incompatible types there could also be a field removal/complement like in elm-lang's records. If there is intersect, why couldn't there be removal and other set operations, like include only fields in both types.
Complement example:
interface PersonWithAddress { name: string; age: number; address: string } interface Person = PersonWithAddress - { address } // Remove field address // Person is now interface { name: string; age: number; }Complement could work as well with other interfaces:
interface A { a: string; b: number; } interface B { b: number; c: string; } interface C = A - B; // C is now { a: string; }With complement in place, it's now possible to use intersection both ways without errors:
interface A { a: string; c: string; } interface B { b: string; c: number } type AB = (A - { c }) & B // { a: string; b: string: c: number }; type BA = (B - { c }) & A // { a: string; b: string: c: string };And it would not cause errors.
P.S. when thinking these as set operations, the word "intersection" is misleading because A intersection B in above example would be empty set! They have nothing in common.
Jari Pennanen (@Ciantic) It's confusing a bit, but it helps to think about intersection of types, not of their members. An intersection of two types is the union of their members, because the resulting intersection then belongs to both types.
In simpler scalar types intersection has more intuitive results, i.e. the intersection of signed and unsigned byte is -128...127 & 0...255 = 0...127. The resulting values belong to both types.
Also I agree order should not matter, identical properties should merge, incompatible ones should error out. That's the only way to ensure the resulting type is truly an intersection belonging to both types.
+1 for interception types.
But I'm confused with the semantic of interception of primitive types, e.g. what should
string & numbermean? Flow type says it is meaningless:Not all intersection types make sense. For example, no value has type number & string since there is no value that can have both of those types.
However if interception of primitive types is not allowed, some use cases such as "interface members conflict" can't be modeled properly.
Duan Yao (@duanyao) It can be modelled properly - but only where it makes sense. It's just that some types cannot intersect because they involve a contradiction. They disagree about the type of some member, in a way that cannot be reconciled. If we make such a request, the compiler is maximally helpful if it rejects it.
Daniel Earwicker (@danielearwicker) Yes, I am aware of the contradiction. But sometimes the contradiction only exists in TS side, not JS side. In these cases we usually use
anyto bypass TS type checker -- I wonder if there are better options thanany.If conflicting types are allowed, just use union types, which are already
part of typescript? (e.g MyClass | MyOtherClass)On Fri, Jun 5, 2015 at 11:06 AM, Duan Yao notifications@github.com wrote:
Daniel Earwicker (@danielearwicker) https://github.com/danielearwicker Yes, I am aware of
the contradiction. But sometimes the contradiction only exists in TS side,
not JS side. In these cases we usually use any to bypass TS type checker
-- I wonder if there are better options than any.—
Reply to this email directly or view it on GitHub
#1256 (comment)
.+1 again for this. It is needed not only by today's
Object.assignbut also by ES7's object spreadMichel Weststrate (@mweststrate) 'cause that would make a type be either MyClass or MyOtherClass, instead of the actual union of the members:
{a: string, b: number} & {d: string, b:string[]} => {a:string, b: number|string[], d:string}.For now, for Object.assign, I am using an overloaded definition in the lines of:
function assign<A>(a: {}, b: A): A; function assign<A>(a: A, b: A): A; function assign<A, B>(a: A, b: B): any; // vs A & BThis works, and is kindof better than the any approach proposed by Duan Yao (@duanyao), because it does help the TS type checker in the nontrivial cases of A and B being of the same type and cloning an object (
Object.assign({}, {a:2});). Still 👍 for type intersections.Michel Weststrate (@mweststrate) The problem of
{a: string, b: number} & {d: string, b:string[]} => {a:string, b: number|string[], d:string}is that{a:string, b: number|string[], d:string}is assignable to none of its super types.Ah indeed, overlooked both items. Thanks :)
On Tue, Jun 16, 2015 at 3:09 AM, Duan Yao notifications@github.com wrote:
Michel Weststrate (@mweststrate) https://github.com/mweststrate The problem of {a: string,
b: number} & {d: string, b:string[]} => {a:string, b: number|string[],
d:string} is that {a:string, b: number|string[], d:string} is assignable
to none of its super types.—
Reply to this email directly or view it on GitHub
#1256 (comment)
.+1
I am looking forward an expressive solution for something likefunction (assertAPI, assertExtension) { return mix(assertAPI, assertExtension) }and intersection type would fit right in.+1 for intersection types.
In Flow, intersection types are used to mimic function overloading:
/* @flow */ declare var f: ((x: number) => void) & ((x: string) => void); f('');In TypeScript, we use union types to support function overloading.
function f(x: number | x: string): void { ... }These two functions actually have the same type because TypeScript used union types to encode intersection types of Flow. Intersection types are the dual of union types. When an arrow is distributed over a union, the union changes to an intersection.
(A -> T) & (B -> T) <: (A | B) -> TI think adding intersection types makes the type system more orthogonal as we often use intersection types to encode union types or union types to encode intersection types. In case of function overloading, I think union types look more natural to most programmers. But typing
Object.assignwith union types seems not trivial. (Or is it possible?)Kwang Yul Seo (@kseo) Just a side note, flow's intersection type is problematic. Please refer to facebook/flow#342 and https://github.com/facebook/flow/blob/master/tests/intersection/test.js
For TypeScript, because function is bivariant, there is probably fewer problems with intersection type
- locked and limited conversation to collaborators
on Jun 18, 2018
Support intersection types ala flowtype