This is very cool! It'll be great to be able to have stronger typings for all the sorts of utility-type function this will support.

Just curious, would this allow for typings for a function like_.omit? As far as I can tell, this would require an additional, orthogonal, type operator?

functionomit<T,KextendskeyofT>(obj:T, ...keys:K[]):Pick<T,(keyofT)-K>;

Can it handle non shallow transformations ?

Like

function deepAssign<T>(obj: T, props: DeepPartial<T>): void;

@jkillian Probably after object-rest is in.

@AlexGalays Nope, I checked out the branch. I didn't find a way this can be done.

I tried 2 level partial, this is the best I could get:

typeDeepPartial<T>={[PinkeyofT]?:T[P]|{[SinkeyofT[P]]?:T[P][S]};};typeA={a:number,b:{c:boolean;d:string;}}typeB=DeepPartial<A>;constb:B={b:{c:{}}};

the second part:{[S in keyof T[P]]?: T[P][S]} always ends up being{} and since interfaces cannot have this signature there is no way to recursively define it:

interfaceDeepPartial<T>{[PinkeyofT]?:T[P]|DeepPartial<T[P]>;// nope :(}

Also, There is no way to distinguish between objects and non-objects so everything will have| {} appended to it.

This PR is really really great so far, I love it ❤️ ❤️

I don't think deep partial is possible at the moment. unless it is defined as a builtin modifier (deepPartial) or magic interfaceDeepPartial<T>

This might be irrelevant but I really cannot hold the urge to say here:

the most exciting moment when using TypeScript is that after a magic pull request, all the sudden I can express a lot of semantics I couldn't before. That's the very freedom in programming world.

This feature is so awesome. Thanks@ahejlsberg and TypeScript team. Make FrontEnd Great Again!

@jkillian No active plans to support a type subtraction operator. It's unclear how such an operator would function across all types. That said, it might be possible to have a limited form that only works on primitive (and thus literal) types and unions thereof. That would suffice for the scenarios where you're subtracting keys from akeyof T.

@AlexGalays@alitaheri We currently restrict recursive use of a mapped type, but it's possible to lift that restriction. However, in actual use we'd still need some form of recursion limiter to avoid spiraling down an infinite series of nested mapped type applications. Ideally some sort of type parameter constraint or modifier you could use on a type alias for a mapped type to indicate that applications should short-circuit for certain types. That way you could for example declareDeepPartial<T> to simply yieldT whenT is a primitive type.

@HerringtonDarkholme Thanks! Really appreciate your excitement for our work.

This is highly exciting! And here I thought strict null check was the best thing since sliced bread, and then this came along.

I think "mapped types" is a somewhat vague term, but seeing the syntactic form of this reminds me of dictionary comprehensions in Python, so perhaps "type comprehension" could be a more descriptive term?

🚲 🏠 comment. Why not usefor as in

typePartial<T>{[forPinkeyofT]?:T[P]}

this makes the iterative nature of the construct more prominent, and would allow for a future branch option usingif a la Python generator expressions.

@mhegazy did you mean something like

typeSubstractType<T,K>{[forPinkeyofTif!(PinkeyofK)]:T[P]}SubstractType<{name:string,age:number},{age:number}>// {name: string}

Type predicate for filtering property?

typescript chose to sacrifice correctness for the sake of "convenience" and ease of learning for attracting as much untutored audience as possible, basically leveling everyone down to the least common denominator

here is the list of hard choices in the making:https://github.com/Microsoft/TypeScript/issues?utf8=%E2%9C%93&q=is%3Aissue%20label%3A%22by%20design%22

@silviogutierrez

Well, in my case I don't want users of my function to extend the base structural type with more properties; I want the full extent of properties declared upfront for typesafety. That rules out returning T & U for me.

Also, be careful with& as it's a bit broken.

If you do

typeA={oops:['1','2','3']}typeB={oops:333}typeC=A&B

You would probably expect an Error, but instead it compiles just fine and the type of oops inside C isstring[] & number which makes no sense.

Partial and the likes seem to have fewer applications that previously thought in their current forms :( It still doesn't solve the React setState problem too :

typeState={veryImportant:number}// This compiles fine with all the mandatory flags (strictNullChecks, etc)// if we use Partial<State>// This is a huge invariant violation and can happen very easily for instance// by setting `veryImportant` to a nullable variable.this.setState({veryImportant:undefined})

Let's start creating some focused bug tickets rather than complaining on this PR :p

I'm trying to write typings forReact's update helper and am struggling a bit.

Here's what I have so far, trying to get things working for a subset of the library's functionality for now. I'm having a few issues which are noted in the code below:

typeCommand={$set:any;}|{$merge:{}}|{$apply(value:any):any;};typeUpdate<T>={[PinkeyofT]?:Update<T[P]>|Command;};declarefunctionupdate<T>(value:T,updateObj:Update<T>);typeFoo={a:number;b:{b1:number;};}letbar:Foo={a:1,b:{b1:2}};// doesn't work without explicit <Foo>:// The type argument for type parameter 'T' cannot be inferred from the usage. Consider specifying the type arguments explicitly.//   Type argument candidate 'Foo' is not a valid type argument because it is not a supertype of candidate '{ a: { $set: number; }; }'.//     Types of property 'a' are incompatible//       Type '{ $set: number; }' is not assignable to type 'number'.update<Foo>(bar,{a:{$set:3}})// also doesn't work without <Foo>update<Foo>(bar,{b:{b1:{$set:4}}})// shouldn't work at all, but doesupdate<Foo>(bar,{b:7});

Any ideas for ways to improve things? At the least, I think it may be an improvement overthe current typings, but I wish it could be even better. Having to explicitly specify the type ofT when callingupdate is a big usability issue in my mind

You can accomplish it thusly:

typeUpdate<T,KextendskeyofT>={[PinK]:Command|NestedUpdate<T[P]>};typeNestedUpdate<T>={[PinkeyofT]?:Command|NestedUpdate<T[P]>};declarefunctionupdate<T,KextendskeyofT>(value:T,updateObj:Update<T,K>);

The problem is that once you get more than one layer deep, it stops actually validating the type.

@PyroVortex Thanks! That works much better! I made anupdated example demonstrating the now working cases and the failure case you mentioned in case anyone's interested

@PyroVortex Seems a bit strange

• K extends keyof T; why use a second type parameter to have a subset of the keys if the keys are already all optional with? anyway?
• When Update is called recursively, It is not passed a subset of keys but the full set of keys which is not consistent with the first level

Anyway, as seen in#12769 (comment), you would have to use the nightly build to get close to what you want without some bad side effects currently in 2.1.4.

Ah, thanks for the reference to#12769@AlexGalays. It looks like Anders' code is quite similar to what I had triedin this comment. Perhaps upgrading to the nightly is the right solution for me here

Is it possible to get the following, get only those props from an object, that present in another object :

functiontakeProps<Obj>(props:{[KinkeyofObj]?:true},obj:Obj){constnewObj:any={}for(letkeyinprops){newObj[key]=obj[key]}returnnewObjas{[Kinkeyoftypeofprops]:number}}takeProps({a:true,c:true},{a:1,b:2,c:3})// => here I wan't be available only `a` and `c`, but get `a`, `b`, and `c`

@whitecolor

functiontakeProps<T,KextendskeyofT>(props:{[PinK]:true},obj:T):{[PinK]:T[P]}

The above declaration has the behavior you are describing.

@PyroVortex thanks very much)

There is another question: is it possible to type a function that gets object map with values that are actually functors and returns mapped object applyingmap method of each functor.

interfaceA{map:()=>number}interfaceB{map:()=>string}leta:A={map:()=>1}letb:B={map:()=>'str'}functiongetMapped(sources:{[index:string]:{map:()=>any}}){// implementationconstmapped:{[keyinkeyoftypeofsources]:any}={}for(constkeyinsources){mapped[key]=sources[key].map()}returnmapped}getMapped({a, b}).a// => should be 1getMapped({a, b}).b// => should be 'str'

Yes

interfaceA{map:()=>number}interfaceB{map:()=>string}leta:A={map:()=>1}letb:B={map:()=>'str'}typeMapsTo<T>={map:()=>T}typeMapSources<T>={[KinkeyofT]:MapsTo<T[K]>}functiongetMapped<T>(sources:MapSources<T>):T{constmapped:any={}for(constkeyinsources){mapped[key]=sources[key].map()}returnmapped}getMapped({a, b}).a// => should be 1getMapped({a, b}).b// => should be 'str'

Any advice on how this can be accomplished a "functor" with two mapping methods :

consta={mapR:()=>1,mapT:()=>true}constb={mapR:()=>'str',mapT:()=>false}typeMapsTo<T,R>={mapT:()=>T,mapR:()=>R}typeMapSources<T,R>={[Kinkeyof(T&R)]:MapsTo<T[K],R[K]>}functiongetMapped<T,R>(sources:MapSources<T,R>):{T:T,R:R}{constmapped:any={T:{},R:{}}for(constkeyinsources){mapped.T[key]=sources[key].mapT()mapped.R[key]=sources[key].mapR()}returnmapped}getMapped({ a, b}).R.a// => should be 1getMapped({ a, b}).R.b// => should be 'str'getMapped({ a, b}).T.a// => should be truegetMapped({ a, b}).T.b// => should be false

@whitecolor you might want to try thegitter channel for typescript

Anyway, here is the solution:http://bit.ly/2od3xP5

The reason why the original doesn't work is because all the keys of T & R are not necessarily present in both T and R, so nothing is known about T[K] and R[K]. Moving the & operator to the argument level ensures that the argument is a source of both kinds of "maps"