Flow version: 0.117.1

Expected behavior

const string = "ABC";

string.charAt();
string.charCodeAt();
string.codePointAt();
// ^ no errors

const maybeANumber = string.codePointAt(100);

Math.round(maybeANumber);
// ^ errors because maybeANumber could be undefined

if (typeof maybeANumber === "number") {
	Math.round(maybeANumber);
	// ^ should be fine now because we checked it this time
}

Actual behavior

const string = "ABC";

string.charAt();
string.charCodeAt();
string.codePointAt();
// ^ errors "Cannot call `string.[...]` because  function [1] requires another argument."

const maybeANumber = string.codePointAt(100);

Math.round(maybeANumber);
// ^ doesn't error but maybeANumber could be undefined

• Link to Try-Flow or Github repo:
  here

Explanation

In my opinion, the definitions of these methods are kind of wrong, because

1. they don't actually require an argument; passing no argument means NaN which means 0 in this context
2. codePointAt could return undefined when pos is greater than the string's length (ref)
3. there's no reason for the charAt parameter being called pos instead of index while the others are not (ref)
   • MDN only calls the codePointAt parameter pos (ref)
   • TC39 calls all of them pos, but also "index" in their explanations (ref)
   • we developers probably would all call them index

Point 1 is debatable though, because ECMAScript actually specifies this:
String.prototype.charCodeAt ( pos )
and not
String.prototype.charCodeAt ( [ pos ] )
which they normally do for actually optional parameters, but in this case, pos will always get converted to NaN if it's undefined anyways. And passing NaN to those methods always returns the first index.
BUT, for example the flow definition of the global function parseInt is technically also not following ECMAScript. Flow says that parseInt accepts mixed as string, but it doesn't. And it says that radix is optional, but it actually isn't. Well, it won't throw, but almost every function of core JavaScript won't throw because of type-juggling and intelligent implementation. I get why Flow allows mixed here, otherwise we would have a pretty hard time checking our strings.
Same goes for isNaN for example. Would be weird if Flow errors on isNaN("test") just because we wanted to check that value, right?
In my opinion, string.charCodeAt() to get the first index should be allowed. It's a common pattern.

Point 2 should be pretty clear.

Point 3 is not that important but I think we should decide on one parameter name for all three methods here.

So my proposal is that this:

	// ...
	charAt(pos: number): string;
    charCodeAt(index: number): number;
    codePointAt(index: number): number;
	// ...

should be this:

	// ...
	charAt(index?: number): string;
    charCodeAt(index?: number): number;
    codePointAt(index?: number): number | undefined;
	// ...

or maybe just this:

	// ...
	charAt(index: number): string;
    charCodeAt(index: number): number;
    codePointAt(index: number): number | undefined;
	// ...

Thoughts?