5

I want to assign a number to an object's field based on some condition like this:

function maybeANumber(): number | undefined {
  const n = Math.random();
  return n > 0.5 ? n : undefined;
}

function maybeSetNumber(target: any, field: any) {
  const num = maybeANumber();
  if (num !== undefined) {
    target[field] = num;
  }
}

This works because I used any liberally, but how can I type this correctly, so that it detects type errors:


interface Foo {
  a: string,
  b: number,
}

const foo: Foo = { a: "", b: 0 };

maybeSetNumber(foo, "a"); // Should be a compile-time error.
maybeSetNumber(foo, "b"); // Should be a ok.

Is there any way to do this?

Edit: Important clarification: the field names are static. I don't need it to work with arbitrary strings. I've tried a load of stuff with keyof but couldn't quite figure it out.

Timmmm
  • 88,195
  • 71
  • 364
  • 509
  • 1
    The issue is that you've crossed an abstraction boundary, where the typechecker won't open the function and substitute the argument for the constant for you. Have you made this function to attempt a set based on dynamic property names? – concat Sep 23 '20 at 20:08
  • Good point I should have specified: the field names are static - I don't need it to work with arbitrary strings (which would be impossible as you say). – Timmmm Sep 23 '20 at 20:14

4 Answers4

5

You can use generics in your maybeSetNumber() signature to say that field is of a generic property key type (K extends PropertyKey), and target is of a type with a number value at that key (Record<K, number> using the Record utility type):

function maybeSetNumber<K extends PropertyKey>(target: Record<K, number>, field: K) {
  const num = maybeANumber();
  if (num !== undefined) {
    target[field] = num;
  }
}

This will give the behaviors you want:

maybeSetNumber(foo, "a"); // error!
// ----------> ~~~
// Types of property 'a' are incompatible.
maybeSetNumber(foo, "b"); // okay

Warning: TypeScript isn't perfectly sound, so this will still let you do some unsafe things if you start using types which are narrower than number:

interface Oops { x: 2 | 3 }
const o: Oops = { x: 2 };
maybeSetNumber(o, "x"); // no error, but could be bad if we set o.x to some number < 1

It is also possible to make the signature such that the error above is on "a" and not on foo. This way is more complicated and requires at least one type assertion since the compiler doesn't understand the implication:

type KeysMatching<T, V> = { [K in keyof T]: V extends T[K] ? K : never }[keyof T]
function maybeSetNumber2<T>(target: T, field: KeysMatching<T, number>) {
  const num = maybeANumber();
  if (num !== undefined) {
    target[field] = num as any; // need a type assertion here
  }
}

maybeSetNumber2(foo, "a"); // error!
// ----------------> ~~~
// Argument of type '"a"' is not assignable to parameter of type '"b"'.
maybeSetNumber2(foo, "b"); // okay

This doesn't suffer from the same problem with Oops,

maybeSetNumber2(o, "x"); // error!

but there are still likely edge cases around soundness. TypeScript often assumes that if you can read a value of type X from a property then you can write a value of type X to that property. This is fine until it isn't. In any case either of these will be better than any.

Playground link to code

jcalz
  • 264,269
  • 27
  • 359
  • 360
2

I would type maybeSetNumber like this:

function maybeSetNumber<F extends string>(target: { [key in F]: number }, field: F) {
  const num = maybeANumber();
  if (num !== undefined) {
    target[field] = num;
  }
}

Playground link

GOTO 0
  • 42,323
  • 22
  • 125
  • 158
  • This would require an object that only has properties of type number, no? Did you test this? – Ruan Mendes Sep 23 '20 at 20:24
  • I added a Playground link. – GOTO 0 Sep 23 '20 at 20:36
  • 1
    I see, it's a lot like jcalz first answer, but simpler since it doesn't use `Record`. I have to say I don't fully understand but the hint is that the error is on the object, not the key – Ruan Mendes Sep 23 '20 at 20:42
  • 1
    I like jcalz's solution better because it uses `PropertyKey` rather than `string`, and so it also works well with fields that have numeric (or symbol) keys. – GOTO 0 Sep 23 '20 at 20:53
0

The other answers here are practically useful — I just want to offer a fundamental reason why this isn't possible without type assertions. In order to perform the set target[field]: O[K] = num, we need to assert that O[K]: number of course. However:

  • The only static constraints on generics must all be contained in the angle brackets in the function head;
  • These can only take the form of a single generic type variable and a suptyping relation; and
  • The language's design applies constraints forward from the angle brackets to the rest of the body, but not the other way around: i.e. it's impossible to create a constraint in the body or the arguments that will imply anything backwards about the generics in those angle brackets.

Unfortunately for us, we want to make an assertion about O[K], which is not a single type variable, and the arguments/body can't help out.

The forward flow of constraints from contexts to bodies is common in other, distant languages with type contexts — Haskell comes to mind for example. I'm not familiar enough with typechecker implementation to know if this is a theoretical issue about decidability, but either way, the bottom line is that Typescript's type contexts just aren't powerful enough at the moment to allow us to make this assertion.

concat
  • 3,107
  • 16
  • 30
-1

In languages without union types, one way to deal with this is multiple return values, in languages which support that (because you're really trying to return two values, a number, and an indicator whether to use the number, you're trying to repurpose the return value's type as an attribute flag attached to the returned number). In that case, return a dummy integer if the "use" flag is false.

I found an example of how to do this in Javascript here: Return multiple values in JavaScript?

John Bayko
  • 746
  • 4
  • 7