Repository: TypeScript
Issue: Proposal: support pathof along with current keyof 
Labels: Suggestion,Awaiting More Feedback

<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

## Problem - What are users having difficulty with?
While using popular libraries for their day to day development needs, developers can find them disjoint from typesafe philosophy even if they do have the needed typings. This is true for frequently used libraries such as lodash and immutablejs that access or set properties via paths. It is up to the developers to to preserve typesafety by expressing complex types using the amazing power that  typescript gives them. The only obstacle is the absence of a way to express the type that represnts legit object paths for a specific type.  
## Current state
We can currently do this only for shallow objects where paths can be simply expressed as the keys of a  specific type. 
## Example Issue
In an effort to play with stricter typings for immutablejs map I created this tiny project :
https://github.com/agalazis/typed-map/
(as a side note my personal view is that immutable js map is not a conventional map that should be represented with map<keyType, valueType> since it represents a map that matches a specific type rather than just a key,value data structure as demonstarated in `src/examples`)

 The type I created was just this (only playing with get and set):
```ts
export type TypedMap<T> = {
  get: <K extends keyof T >(k:K) => T[K];
  set: <K extends keyof T >(k:K, v:T[K]) => TypedMap<T>;
}
```

Simple enough, leveraging all the expressiveness of typescript.  
## Example  usage of the proposed solution:
If I could replace  keyof with pathof in order  to express possible path strings  and also used T[P] as the path type I would be able to completely cover this use-case :
```ts
export type TypedMap<T> = {
  get: <P extends pathof T >(p:P) => T[P];
  set: <P extends pathof T>(p:P, v:T[P]) => TypedMap<T>;
}
```
## Possible usage in the following libraries:
- lodash
- immutable
- ramda
- anything built on top of them

### Why bother since this does not involve facilitating any  feature of ES standard?(and is somewhat an unconventional feature)
1. We will be able to perform type-safe updates using existing js immutability libraries similar to what you can achieve in other languages (eg. [skala lense](http://koff.io/posts/292173-lens-in-scala/)).
2. This feature complies with typescript goals:
 - Statically identify constructs that are likely to be errors.
 - Provide a structuring mechanism for larger pieces of code (the above-mentioned libraries are used every day in big projects imagine the chaos that can be created. Despite exhaustive unit testing, intellisense is a must ;) ).
- Strike a balance between correctness and productivity.
4. This feature improves compile time checks  and sticks to the mindset of not having to deal with any runtime functionality
3. There are no side effects in the generated js code 

### Alternatives
While digging further into the issue an alternative solution is to be able to spread keyof recursively. This will allow us to be creative and build our own solution as per:
https://github.com/Microsoft/TypeScript/issues/20423#issuecomment-349776005
The drawbacks of the alternative solution if doable are:
- performance 
- lack of cyclic reference support

### Implementation Suggestions
The optimal (if implemented in the language) would be to not compute the full nested object paths but only the paths used via pathof ie when declaring something as path of x just accept it as pathof x then when a value is assigned just validate it is pathOf x( the compiler could also have some sort of caching so that it doesn't recalculate paths). 
This will also solve the issue with cyclic references since paths will be finite anw.