When an object key has annotated type, the key and value are unchecked

[wchargin]

The following code should obviously have a type error, but does not:

// @flow
const key: string = "magic";
const o: {[string]: number} = {[key]: "I am not a number"};  // no type error!!!
o.magic.toFixed();  // runtime error

Some more examples:

// @flow
const annotated: string = "hi";
({[annotated]: "I am not a number"}: {[string]: number});  // no error!!!
({[annotated]: "I am not a number"}: {|[string]: number|});  // even when exact
({[annotated]: "I am not a number"}: {+[string]: number});  // or covariant
({[annotated]: "I am not a number"}: {|+[string]: number|});  // or both

const inferred = "hi";
({[inferred]: "I am not a number"}: {[string]: number});  // properly fails

Edit: It appears that the key is not checked, either:

// @flow
type Fruit = "APPLE" | "ORANGE";
const properlyFails1: {[Fruit]: number} = {BRICK: 123};
const properlyFails2: {[Fruit]: number} = {["BRICK"]: 234};
const wat3: {[Fruit]: number} = {[("BRICK": string)]: 345};  // no error!!!
const wat4: {[Fruit]: number} = {[("BRICK": string)]: "wat"};  // no error!!!

[wchargin]

This yields coerce:

// @flow
function coerce<T, U>(t: T): U {
  const key: string = "magic";
  const o: {[string]: U} = {[key]: t};
  return o.magic;
}
const twelve: number = coerce("twelve");  // oops!

[sliminality]

I keep running into this when indexing an object using a union type. It would be nice to have some way to use exact object types to verify exhaustivity.

For example, the following variant of the OP's example typechecks, even though it clearly shouldn't:

type Enum = 'A' | 'B' | 'C';

const partialMap: {[Enum]: () => mixed} = {
  A: () => {},
  B: () => {},
};

partialMap['C']();  // will fail at runtime

If the annotation on partialMap is removed, the example will correctly fail to typecheck and generally guard against undefined lookups. However, this workaround is obviously not ideal, as it accepts keys that aren't part of Enum.

type Enum = 'A' | 'B' | 'C';

const partialMap = {
  A: () => {},
  B: () => {},
  randomOtherProperty: () => {},  // should fail
};

Seems related to #3162.

[wchargin]

However, this workaround is obviously not ideal, as it accepts keys
that aren't part of Enum.

A workaround that I’ve used in the past:

// @flow
type Enum = 'A' | 'B' | 'C';

const partialMap = {
  A: () => {},
  B: () => {},
  randomOtherProperty: () => {},  // should fail
};
/*::
// Static check for soundness
(partialMap: {[Enum]: () => mixed});
// Static check for completeness
((x: Enum): mixed => partialMap[x]);
*/

[sliminality]

Ah, thanks! That's a neat workaround.

In this case, it does appear that unsound lookups are intended behavior:

When an object type has an indexer property, property accesses are assumed to have the annotated type, even if the object does not have a value in that slot at runtime. It is the programmer’s responsibility to ensure the access is safe, as with arrays.

var obj: { [number]: string } = {};
obj[42].length; // No type error, but will throw at runtime

I suppose it's a design decision, albeit one I personally disagree with...oh well.

[villesau]

Here is the culprit: https://github.com/facebook/flow/blob/master/src/typing/flow_js.ml#L6895

Looks like iter_real_props assumes that property is always something concrete, not just string. The iterator returns property name as string s, which is not available in this case as it's just string. To fix this, https://github.com/facebook/flow/blob/master/src/typing/flow_js.ml#L6895-L6954 might need some refactoring. more thorough debugging here: #7241

[villesau]

@sarahlim here is an issue (proposal?) for making indexed object properties maybe types: #6980

[vicapow]

I'm going to go ahead and merge this with #7392 if that's okay. To summarize, accessing an object with a string is unsound. Although it was an intentional design decision, this should be reconsidered. One way to mitigate this for now is to turn on "coverage" reporting in your IDE.

[wchargin]

Wait, what? It’s an intentional design decision to make object access
unsound when the subscript’s type is annotated, but not when it’s
inferred?

// @flow
({[("one": string)]: "I am not a number"}: {[boolean]: number});  // no error(?!)
({["one"]: "I am not a number"}: {[boolean]: number});  // properly fails on two counts

Why should replacing "one" with ("one": string) ever silence a type
error?

I understand that subscripting arrays, et al. is unsound by design, but
surely this is just a bug? (If not, then I definitely agree that it
should be reconsidered! :-) )

[vicapow]

Reading this again, they may be related but separate issues.