Better type declaration for `prop` function about fxts

[mass2527]

@Phryxia @ppeeou
I really appreciate the great explanation!

I initially believed that the prop function was only used with pure JavaScript objects, not object values. Now I understand the reason why type definitions were written the way they are currently.

[Phryxia]

@mass2527 cc @ppeeou

Currently, invalid keys can be passed without any error.

I think first case is intended behavior. As #doc says, it can receive non-key property of given obj. Maybe this is becasue prop can be used in pipe to replace verbose map like following

pipe([
    { x: 0 },
    { x: 1 },
    { y: 2 },
  ],
  map(
    obj => obj.x
  )
)

And it has fairly nice return type also! #source If you're facing some problem because of unconstrained parameter type, can you tell me so that I can help for another approach?

If you want just to restrict key property via function, I recommend this implementation. (Although I'm not sure what you want through this)

function getProperty<T, K extends keyof T>(key: K, obj: T): T[K] {
    return obj[key]
}

Additionally, any value can currently be passed to obj as an argument.

Since function is also just an object, therefore there is no reason to prohibit it. Even they have some their own properties.

const f = () => {}
console.log(Object.getOwnPropertyNames(f)) // ['length', 'name']

After value being initiated from number or boolean literal, they're also being object. they can also have properties.

For example:

const x = 1 // definetly number literal
x.toPrecision(2) // this is valid
x.foo = 'bar' // this also valid (at least for js)

Maybe #this might helps your understanding.

[ppeeou]

@mass2527 @Phryxia
That's right, this is the intended behavior.

Since ramdajs also returns the same type, we judged it to be more familiar to users.
https://ramdajs.com/docs/#prop