facebook / facebook/flow

Support optional parameters in the middle of the parameter list

オープン
#433 コメント 0 件 リアクション 2 件 担当者 0 名 GitHub で見る
wishlist
主要言語
Rust
スター
22.3k
フォーク
1.9k
PR マージ指標
30日以内にマージされた PR はありません

説明

This pattern comes up in external libraries, and has been an issue before in the type declarations for node libraries (#333).

Although @gabelevi made it clear there is ambiguity here, it feels like we should be able to support any common case. Take the following example:

```
declare function readFile(
filename: string,
options?: Object | string,
callback: (err: ?Error, data: Buffer) => void
): void;
```

(Omitting the callback does lead to an exception at runtime, so marking the callback as optional isn't very satisfying.)

The [implementation of readFile in node](https://github.com/joyent/node/blob/4d9c81b7e2522c5d5d9d35058cbb0bce1228d360/lib/fs.js#L246) shows how the runtime type checking works. This to me is similar to flow's own refinements.

I think we could consider the above definition of `readFile` to be a short-hand notation for a set of overloaded declarations:

```
declare function readFile(
filename: string,
options: Object | string,
callback: (err: ?Error, data: Buffer) => void
): void;
declare function readFile(
filename: string,
callback: (err: ?Error, data: Buffer) => void
): void;
```

Flow would then use the arity of the call site to disambiguate between the two overrides. In other cases, we should be able to use types to disambiguate.

Yes, there will be ambiguous cases, and flow should complain in those situations. If something is ambiguous in flow, it's probably ambiguous to the runtime as well. I don't think we will find ambiguous cases in the APIs we want to declare, but we seem to run into unambiguous cases a lot!

コントリビューションガイド

コントリビューションガイドを開く

評価

この issue はまだ評価されていません。

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。