ここで構文について議論の余地があることをお勧めします。 TypeScriptは、共用体型の先頭パイプを許可するようになったためです。

class B {}

type A = | number | 
B

セミコロンの自動挿入のおかげで、今すぐコンパイルされ、 type A = number | Bと同等になります。

正確なタイプが導入された場合、これは私が期待しないかもしれないと思います。

実現したかどうかはわかりませんが、参考までにhttps://github.com/Microsoft/TypeScript/issues/7481

{| ... |}構文が採用された場合、マップされた型に基づいて構築できるため、次のように記述できます。

type Exact<T> = {|
    [P in keyof T]: P[T]
|}

次に、 Exact<User>書くことができます。

TypeScriptと比較して、これはおそらく私がFlowから見逃している最後のことです。

Object.assign例は特に優れています。 TypeScriptが今日のように動作する理由は理解していますが、ほとんどの場合、正確な型が必要です。

@HerringtonDarkholmeありがとう。 私の最初の問題はそれを述べました、しかし誰かがとにかくより良い構文を持っているので私は最後にそれを省略しました、彼らはそうすることがわかりました😄

@DanielRosenwasserそれははるかに合理的に見えます、ありがとう！

@wallverbそうは思いませんが、その機能が存在することも確認したいのですが😄

型の和集合を表現したい場合はどうなりますか？正確なものとそうでないものがありますか？ 推奨される構文では、間隔に特別な注意が払われている場合でも、エラーが発生しやすく、読みにくくなります。

|Type1| | |Type2| | Type3 | |Type4| | Type5 | |Type6|

組合のどのメンバーが正確でないかすぐにわかりますか？

そして、慎重な間隔なしで？

|Type1|||Type2||Type3||Type4||Type5||Type6|

（回答： Type3 、 Type5 ）

@rotemdan上記の回答を参照してください。代わりに、一般的な型Extactます。これは、私の提案よりも堅実な提案です。 これが好ましいアプローチだと思います。

また、エディターのヒント、プレビューポップアップ、コンパイラメッセージでどのように表示されるかについても懸念があります。 現在、型エイリアスは生の型式に「フラット化」されています。 エイリアスは保持されないため、それを打ち消すために特別な手段が適用されない限り、理解できない表現が引き続きエディターに表示されます。

この構文が、Typescriptと同じ構文のユニオンを持つFlowのようなプログラミング言語に受け入れられたとは信じがたいです。 私には、既存の構文と根本的に矛盾する欠陥のある構文を導入し、それを「カバー」するために非常に一生懸命努力するのは賢明ではないようです。

興味深い（面白い？）代替手段の1つは、 onlyような修飾子を使用することです。 私は数ヶ月前にこの提案の草案を持っていたと思いますが、私はそれを提出しませんでした：

function test(a: only string, b: only User) {};

それは当時私が見つけた最高の構文でした。

_編集_： justも機能する可能性がありますか？

function test(a: just string, b: just User) {};

_（編集：構文は元々記名型の修飾子用だったことを思い出しましたが、実際には問題ではないと思います。2つの概念は十分に近いので、これらのキーワードもここで機能する可能性があります）_

たぶん、2つのわずかに異なるタイプのマッチングを説明するために、両方のキーワードを導入できるのではないかと思いました。

• ここで説明するように、正確な構造マッチングのためのjust T （意味：「正確にT 」）。
• 名目マッチングの場合はonly T （意味：「一意にT 」）。

名目上の一致は、正確な構造的一致のさらに「より厳密な」バージョンと見なすことができます。 これは、型が構造的に同一である必要があるだけでなく、値自体が指定されたものとまったく同じ型識別子に関連付けられている必要があることを意味します。 これは、インターフェイスとクラスに加えて、型エイリアスをサポートする場合とサポートしない場合があります。

個人的には、微妙な違いがそれほど混乱を招くとは思いませんが、 onlyような名目上の修飾子の概念が適切かどうかを判断するのはTypescriptチーム次第だと思います。 私はこれをオプションとして提案しているだけです。

_（編集：クラスで使用する場合のonlyに関する注意：基本クラスが参照されるときに名目上のサブクラスを許可するかどうかについては、ここであいまいさがあります-個別に説明する必要があると思います。程度は低いですが、インターフェイスについても同じことが考えられますが、現時点ではそれほど有用だとは思いません）_

これは、変装した減算タイプのようなもののようです。 これらの問題は関連している可能性があります： https ： https://github.com/Microsoft/TypeScript/issues/7993

@ethanresnickなぜあなたはそれを信じますか？

これは、私が現在取り組んでいるコードベースで非常に役立ちます。 これがすでに言語の一部である場合、今日はエラーの追跡に費やしていなかったでしょう。

（おそらく他のエラーですが、この特定のエラーではありません😉）

Flowに触発されたパイプ構文は好きではありません。 インターフェイスの背後にあるexactキーワードのようなものは読みやすくなります。

exact interface Foo {}

@ mohsen1ほとんどの人は、式の位置にExactジェネリック型を使用すると確信しているので、それほど重要ではありません。 ただし、以前はエクスポート専用に予約されていたinterfaceキーワードの左側が時期尚早にオーバーロードされている可能性があるため（JavaScript値との整合性- export const foo = {} ）、そのような提案に関心があります。 また、そのキーワードがタイプにも使用できる可能性があることも示しています（たとえば、 exact type Foo = {}場合、 export exact interface Foo {} ）。

{| |}構文では、 extendsはどのように機能しますか？ interface Bar extends Foo {| |}が正確でない場合、 Fooは正確になりますか？

exactキーワードを使用すると、インターフェイスが正確かどうかを簡単に判断できると思います。 typeでも機能します（すべきですか？）。

interface Foo {}
type Bar = exact Foo

追加のデータが黙って無視され、バグを見つけるのが困難または非常に困難になる可能性があるため、すべてのオプションのプロパティを持つオブジェクトを取得するAWS SDKなどのデータベースまたはSDKへのデータベースまたはネットワーク呼び出しを介して機能するものに非常に役立ちます：rose：

@ mohsen1キーワードアプローチを使用しても同じ質問が存在するため、この質問は構文とは無関係のようです。 個人的に、私には好ましい答えがなく、それに答えるために既存の期待を試す必要があります-しかし、私の最初の反応は、 Fooが正確であるかどうかは問題ではないということです。

exactキーワードの使用法はあいまいに見えます- exact interface Foo {}またはtype Foo = exact {}ように使用できると言っていますか？ exact Foo | Barどういう意味ですか？ 一般的なアプローチを使用し、既存のパターンを操作することは、再発明や学習が必要ないことを意味します。 これはinterface Foo {||} （これがここでの唯一の新しいものです）、次にtype Foo = Exact<{}>とExact<Foo> | Barです。

私たちはこれについてかなり長い間話しました。 議論を要約しようと思います。

過剰なプロパティチェック

正確なタイプは、追加のプロパティを検出するための単なる方法です。 最初に過剰プロパティチェック（EPC）を実装したとき、正確な型の需要は大幅に減少しました。 EPCはおそらく私たちが取った最大の重大な変更でしたが、それは報われました。 EPCが過剰なプロパティを検出

正確なタイプが必要なほとんどの場合、EPCをよりスマートにすることでそれを修正したいと思います。 ここで重要なのは、ターゲットタイプが共用体タイプの場合です。これをバグ修正として使用します（EPCはここはずですが、まだ実装されていません）。

すべてオプションタイプ

EPCに関連するのは、すべてオプション型（私は「弱い」型と呼んでいます）の問題です。 ほとんどの場合、すべての弱いタイプは正確である必要があります。 弱い型の検出を実装する必要があります（＃7485 /＃3842）。 ここでの唯一のブロッカーは交差型であり、実装にさらに複雑さが必要です。

誰のタイプが正確ですか？

正確なタイプで最初に見られる大きな問題は、どのタイプを正確にマークする必要があるかが本当に不明確であるということです。

スペクトルの一端には、固定ドメイン外の独自のキーを持つオブジェクトが与えられた場合に、文字通り例外をスローする（またはその他の方法で悪いことをする）関数があります。 これらはごくわずかであり、その間にあります（メモリから例を挙げられません）。 真ん中には黙って無視する機能があります
未知のプロパティ（ほとんどすべて）。 そしてもう一方の端には、すべてのプロパティを一般的に操作する関数があります（例： Object.keys ）。

明らかに、「追加のデータが与えられた場合にスローする」関数は、正確な型を受け入れるものとしてマークする必要があります。 しかし、真ん中はどうですか？ 人々はおそらく反対するでしょう。 Point2D / Point3Dは良い例です- Point3Dを渡さないようにするには、 magnitude関数の型を(p: exact Point2D) => numberにする必要があると合理的に言うことができます。 Point3D 。 しかし、なぜ{ x: 3, y: 14, units: 'meters' }オブジェクトをその関数に渡せないのですか？ これがEPCの出番です。確実に破棄される場所でその「余分な」 unitsプロパティを検出したいのですが、エイリアシングを伴う呼び出しを実際にブロックしたくないのです。

仮定の違反/インスタンス化の問題

正確なタイプが無効になるという基本的な信条がいくつかあります。 たとえば、タイプT & Uは常にTに割り当て可能であると想定されていますが、 Tが正確なタイプである場合、これは失敗します。 このT & U -> T原則を使用する汎用関数があるかもしれないが、正確な型でインスタンス化されたT関数を呼び出すため、これは問題があります。 したがって、このサウンドを作成する方法はありません（インスタンス化でエラーが発生することは実際には問題ありません）-必ずしもブロッカーである必要はありませんが、ジェネリック関数が手動でインスタンス化されたバージョンよりも寛容であると混乱します！

また、 Tは常にT | Uに割り当て可能であると想定されていますが、 Uが正確なタイプである場合、このルールを適用する方法は明らかではありません。 { s: "hello", n: 3 }を{ s: string } | Exact<{ n: number }>割り当てることnを探して、 sを見るのT -> T | U違反しているため、「いいえ」も間違っているようです。

その他

function f<T extends Exact<{ n: number }>(p: T)の意味は何ですか？ ：混乱している：

多くの場合、本当に必要なのが「自動分離」ユニオンである場合、正確なタイプが必要になります。 つまり、 { type: "name", firstName: "bob", lastName: "bobson" }または{ type: "age", years: 32 }を受け入れることができるが、予測できないことが発生するため、 { type: "age", years: 32, firstName: 'bob" }を受け入れたくないAPIがある場合があります。 「正しい」タイプは間違いなく{ type: "name", firstName: string, lastName: string, age: undefined } | { type: "age", years: number, firstName: undefined, lastName: undefined }が、タイプするのが面倒な良いゴリーです。 このようなタイプを作成するための砂糖について考える可能性があります。

概要：必要なユースケース

私たちの希望する診断は、これが、比較的少数の真に閉じたAPIの外では、 XY問題の解決策であるということです。 可能な限り、EPCを使用して「不良」プロパティを検出する必要があります。 したがって、問題があり、正確なタイプが正しい解決策であると思われる場合は、ここで元の問題を説明してください。パターンのカタログを作成し、侵襲性や混乱が少ない他の解決策があるかどうかを確認できます。

正確なオブジェクトタイプがないことに人々が驚かされる主な場所は、 Object.keysとfor..in彼らは常に'a'|'b'ではなくstringタイプを生成します。 'a'|'b' { a: any, b: any }入力されたものの場合は

https://github.com/Microsoft/TypeScript/issues/14094で述べたように、その他のセクションで説明したように、 {first: string, last: string, fullName: string}が{first: string; last: string} | {fullName: string}準拠しているのは面倒です。

たとえば、タイプT＆Uは常にTに割り当て可能であると想定されていますが、Tが正確なタイプである場合、これは失敗します。

Tが正確なタイプである場合、おそらくT & Uはnever （またはT === U ）です。 右？

または、 UはT正確でないサブセットです

この提案に私を導いた私のユースケースは、reduxレデューサーです。

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>): State {
   return {
       ...state,
       fullName: action.payload // compiles, but it's an programming mistake
   }
}

要約で指摘したように、私の問題は、正確なインターフェイスが必要であるということではなく、spread演算子が正確に機能する必要があるということです。 しかし、spread演算子の動作はJSによって与えられるので、私の頭に浮かぶ唯一の解決策は、戻り型またはインターフェースを正確に定義することです。

私は、の値が代入することを正しく理解していますTにExact<T>誤りでしょうか？

interface Dog {
    name: string;
    isGoodBoy: boolean;
}
let a: Dog = { name: 'Waldo', isGoodBoy: true };
let b: Exact<Dog> = a;

この例では、 DogをExact<Dog>に絞り込むのDog安全ではありませんよね？
この例を考えてみましょう。

interface PossiblyFlyingDog extends Dog {
    canFly: boolean;
}
let c: PossiblyFlyingDog = { ...a, canFly: true };
let d: Dog = c; // this is okay
let e: Exact<Dog> = d; // but this is not

@leonadlerはい、それがアイデアです。 Exact<T>をExact<T>割り当てることしかできませんExactタイプを処理することです（たとえば、リクエストペイロードをanyとして受け取り、有効なExact<T>を出力します）。 ただし、 Exact<T>はT割り当てることができます。

@nerumo

要約で指摘したように、私の問題は、正確なインターフェイスが必要であるということではなく、spread演算子が正確に機能する必要があるということです。 しかし、spread演算子の動作はJSによって与えられるので、私の頭に浮かぶ唯一の解決策は、戻り型またはインターフェースを正確に定義することです。

私は同じ問題にぶつかり、この解決策を見つけました。これは私にとって非常にエレガントな回避策です:)

export type State = {
  readonly counter: number,
  readonly baseCurrency: string,
};

// BAD
export function badReducer(state: State = initialState, action: Action): State {
  if (action.type === INCREASE_COUNTER) {
    return {
      ...state,
      counterTypoError: state.counter + 1, // OK
    }; // it's a bug! but the compiler will not find it 
  }
}

// GOOD
export function goodReducer(state: State = initialState, action: Action): State {
  let partialState: Partial<State> | undefined;

  if (action.type === INCREASE_COUNTER) {
    partialState = {
      counterTypoError: state.counter + 1, // Error: Object literal may only specify known properties, and 'counterTypoError' does not exist in type 'Partial<State>'. 
    }; // now it's showing a typo error correctly 
  }
  if (action.type === CHANGE_BASE_CURRENCY) {
    partialState = { // Error: Types of property 'baseCurrency' are incompatible. Type 'number' is not assignable to type 'string'.
      baseCurrency: 5,
    }; // type errors also works fine 
  }

  return partialState != null ? { ...state, ...partialState } : state;
}

詳細については、私のreduxガイドのこのセクションをご覧ください。

• https://github.com/piotrwitek/react-redux-typescript-guide#spread -operation-with-exact-types-check-to-guard-against-excess-or-mismatched-props

これは、私の制約タイプの提案（＃13257）を使用してユーザーランドで解決できることに注意してください。

type Exact<T> = [
    case U in U extends T && T extends U: T,
];

編集：提案に関連する構文を更新

@piotrwitekありがとうございます。部分トリックは完全に機能し、コードベースにバグがすでに見つかりました;）それは小さな定型コードの価値があります。 しかし、それでも私は@isiahmeadowsに同意しさらに良いでしょう

@piotrwitekがPartialを使用して_ほぼ_私の問題を解決しましたが、Stateインターフェイスがアサリではない場合でもプロパティが未定義になる可能性があります（strictNullChecksを想定しています）。

インターフェイスタイプを保持するために、少し複雑なものになりました。

export function updateWithPartial<S extends object>(current: S, update: Partial<S>): S {
    return Object.assign({}, current, update);
}

export function updateWith<S extends object, K extends keyof S>(current: S, update: {[key in K]: S[key]}): S {
    return Object.assign({}, current, update);
}

interface I {
    foo: string;
    bar: string;
}

const f: I = {foo: "a", bar: "b"}
updateWithPartial(f, {"foo": undefined}).foo.replace("a", "x"); // Compiles, but fails at runtime
updateWith(f, {foo: undefined}).foo.replace("a", "x"); // Does not compile
updateWith(f, {foo: "c"}).foo.replace("a", "x"); // Compiles and works

@asmundgは正しいですが、ソリューションは未定義を受け入れますが、私のソリューションではペイロードに必要なパラメーターを持つアクションクリエーターのみを使用しているため、これは許容されます。これにより、未定義の値が存在しないことが保証されます。 null不可能なプロパティに割り当てられます。
実際、私はこのソリューションを本番環境でかなり長い間使用しており、この問題は発生しませんでしたが、懸念事項をお知らせください。

export const CHANGE_BASE_CURRENCY = 'CHANGE_BASE_CURRENCY';

export const actionCreators = {
  changeBaseCurrency: (payload: string) => ({
    type: CHANGE_BASE_CURRENCY as typeof CHANGE_BASE_CURRENCY, payload,
  }),
}

store.dispatch(actionCreators.changeBaseCurrency()); // Error: Supplied parameters do not match any signature of call target.
store.dispatch(actionCreators.changeBaseCurrency(undefined)); // Argument of type 'undefined' is not assignable to parameter of type 'string'.
store.dispatch(actionCreators.changeBaseCurrency('USD')); // OK => { type: "CHANGE_BASE_CURRENCY", payload: 'USD' }

デモ-オプションでstrictNullChecksを有効にします

必要に応じてnull許容ペイロードを作成することもできます。詳細については、私のガイドをご覧ください： //github.com/piotrwitek/react-redux-typescript-guide#actions

レストタイプがマージされると、この機能を簡単にシンタックスシュガーにすることができます。

提案

型の等価ロジックは厳密にする必要があります。同じプロパティを持つ型、または親型が同じプロパティを持つようにインスタンス化できるRESTプロパティを持つ型のみが一致すると見なされます。 下位互換性を維持するために、合成レストタイプは、すでに存在しない限り、すべてのタイプに追加されます。 新しいフラグ--strictTypesも追加され、合成RESTパラメーターの追加が抑制されます。

--strictTypes未満の同等性：

type A = { x: number, y: string };
type B = { x: number, y: string, ...restB: <T>T };
type C = { x: number, y: string, z: boolean, ...restC: <T>T };

declare const a: A;
declare const b: B;
declare const c: C;

a = b; // Error, type B has extra property: "restB"
a = c; // Error, type C has extra properties: "z", "restC"
b = a; // OK, restB inferred as {}
b = c; // OK, restB inferred as { z: boolean, ...restC: <T>T }

c = a; // Error, type A is missing property: "z"
       // restC inferred as {}

c = b; // Error, type B is missing property: "z"
       // restC inferred as restB 

--strictTypesがオンになっていない場合、 ...rest: <T>TプロパティはタイプA自動的に追加されます。 このようにして、行a = b;とa = c;は、後続の2行の変数bの場合のように、エラーではなくなります。

仮定の違反に関する一言

タイプT＆Uは常にTに割り当て可能であると想定されていますが、Tが正確なタイプである場合、これは失敗します。

はい、 &は偽のロジックを許可しますが、 string & number場合も同様です。 stringとnumberはどちらも、交差できない別個の剛体型ですが、型システムでは許可されています。 正確なタイプも厳密であるため、不整合は依然として一貫しています。 問題は&演算子にあります-それは不健全です。

{s： "hello"、n：3}は{s：string}に割り当て可能ですか| 正確<{n：数値}>。

これは次のように翻訳できます。

type Test = { s: string, ...rest: <T>T } | { n: number }
const x: Test = { s: "hello", n: 3 }; // OK, s: string; rest inferred as { n: number }

したがって、答えは「はい」である必要があります。 非正確な型は、識別子プロパティが存在しない限り、すべての正確な型を包含するため、非正確な型と正確に結合することは安全ではありません。

Re：上記の@RyanCavanaughのコメントにある関数f<T extends Exact<{ n: number }>(p: T) 、私のライブラリの1つに、次の関数を実装したいと思います。

const checkType = <T>() => <U extends Exact<T>>(value: U) => value;

つまり、まったく同じ型のパラメーターを返す関数ですが、同時に、その型が別の型（T）とまったく同じ型であるかどうかも確認します。

これは、両方の要件を満たすために失敗した3つの試行の少し不自然な例です。

1. CorrectObjectに関して過剰なプロパティはありません
2. オブジェクトのタイプとしてHasXを指定せずに、 HasX割り当てることができます

type AllowedFields = "x" | "y";
type CorrectObject = {[field in AllowedFields]?: number | string};
type HasX = { x: number };

function objectLiteralAssignment() {
  const o: CorrectObject = {
    x: 1,
    y: "y",
    // z: "z" // z is correctly prevented to be defined for o by Excess Properties rules
  };

  const oAsHasX: HasX = o; // error: Types of property 'x' are incompatible.
}

function objectMultipleAssignment() {
  const o = {
    x: 1,
    y: "y",
    z: "z",
  };
  const o2 = o as CorrectObject; // succeeds, but undesirable property z is allowed

  type HasX = { x: number };

  const oAsHasX: HasX = o; // succeeds
}

function genericExtends() {
  const checkType = <T>() => <U extends T>(value: U) => value;
  const o = checkType<CorrectObject>()({
    x: 1,
    y: "y",
    z: "z", // undesirable property z is allowed
  }); // o is inferred to be { x: number; y: string; z: string; }

  type HasX = { x: number };

  const oAsHasX: HasX = o; // succeeds
}

ここで、 HasXは非常に単純化された型（実際の型はスキーマ型に対してoをマップします）であり、定数自体とは異なるレイヤーで定義されているため、 oの型を作成できません。 （ CorrectObject & HasX ）になります。

正確なタイプの場合、解決策は次のようになります。

function exactTypes() {
  const checkType = <T>() => <U extends Exact<T>>(value: U) => value;
  const o = checkType<CorrectObject>()({
    x: 1,
    y: "y",
    // z: "z", // undesirable property z is *not* allowed
  }); // o is inferred to be { x: number; y: string; }

  type HasX = { x: number };

  const oAsHasX: HasX = o; // succeeds
}

@ andy-ms

Tが正確なタイプである場合、おそらくT＆Uは決してありません（またはT === U）。 右？

T & UはUがTと互換性がない場合にのみ、 never T & U必要があると思います。たとえば、 TがExact<{x: number | string}> Uが{[field: string]: number}場合、 T & UはExact<{x: number}>

それに対する最初の応答を参照してください。

または、UはTの正確でないサブセットです

UがTに割り当て可能である場合、 T & U === Tと言います。 ただし、 TとUが正確に異なるタイプの場合、 T & U === never 。

あなたの例では、何もしないcheckType関数が必要なのはなぜですか？ なぜconst o: Exact<CorrectObject> = { ... }だけを持っていないのですか？

xが確実に存在し（CorrectObjectではオプション）、number（CorrectObjectではnumber | string）であるという情報が失われるためです。 あるいは、Exactの意味を誤解したかもしれません。それは、すべてのタイプが完全に同じでなければならないことを再帰的に意味するのではなく、無関係なプロパティを防ぐだけだと思いました。

正確な型のサポートと現在のEPCに対するもう1つの考慮事項は、リファクタリングです。抽出変数のリファクタリングが利用可能な場合、抽出された変数が型注釈を導入しない限り、EPCが失われ、非常に冗長になる可能性があります。

正確な型を支持する理由を明確にするために、これは識別された共用体ではなく、オブジェクトリテラルと同時に型costraintを指定できない場合に備えて、スペルミスや誤って無関係なプロパティを対象としています。

@ andy-ms

UがTに割り当て可能である場合、T＆U === Tです。しかし、TとUが正確に異なるタイプである場合、T＆U ===はありません。

&型の演算子は共通部分の演算子であり、その結果は両側の共通のサブセットであり、必ずしもどちらかが等しいとは限りません。 私が考えることができる最も簡単な例：

type T = Exact<{ x?: any, y: any }>;
type U = { x: any, y? any };

ここでT & UなければならないExact<{ x: any, y: any }>の両方の部分集合である、 TおよびU 、どちらもTのサブセットであるU （xがない）もUもT （yがない）のサブセットです。

これは、 T 、 U 、またはT & Uが正確なタイプであるかどうかに関係なく機能するはずです。

@magnushiie良い点があります。正確な型は、幅の広い型からの割り当て可能性を制限できますが、それでも深さの大きい型からの割り当て可能性は許可されます。 したがって、 Exact<{ x: number | string }>をExact<{ x: string | boolean }>と交差させて、 Exact<{ x: string }>を取得できます。 1つの問題は、 xが読み取り専用でない場合、これは実際にはタイプセーフではないということです。厳密な動作を選択することを意味するため、正確なタイプの間違いを修正することをお勧めします。

正確な型は、署名にインデックスを付けるための型引数関係の問題にも使用できます。

interface T {
    [index: string]: string;
}

interface S {
    a: string;
    b: string;
}

interface P extends S {
    c: number;
}

declare function f(t: T);
declare function f2(): P;
const s: S = f2();

f(s); // Error because an interface can have more fields that is not conforming to an index signature
f({ a: '', b: '' }); // No error because literals is exact by default

正確なタイプをチェックするためのハッキーな方法は次のとおりです。

// type we'll be asserting as exact:
interface TextOptions {
  alignment: string;
  color?: string;
  padding?: number;
}

// when used as a return type:
function getDefaultOptions(): ExactReturn<typeof returnValue, TextOptions> {
  const returnValue = { colour: 'blue', alignment: 'right', padding: 1 };
  //             ERROR: ^^ Property 'colour' is missing in type 'TextOptions'.
  return returnValue
}

// when used as a type:
function example(a: TextOptions) {}
const someInput = {padding: 2, colour: '', alignment: 'right'}
example(someInput as Exact<typeof someInput, TextOptions>)
  //          ERROR: ^^ Property 'colour' is missing in type 'TextOptions'.

残念ながら、現在、タイプパラメータとしてExactアサーションを作成することはできないため、呼び出し時に作成する必要があります（つまり、それについて覚えておく必要があります）。

これを機能させるために必要なヘルパーユーティリティは次のとおりです（それらのいくつかについては

type Exact<A, B extends Difference<A, B>> = AssertPassThrough<Difference<A, B>, A, B>
type ExactReturn<A, B extends Difference<A, B>> = B & Exact<A, B>

type AssertPassThrough<Actual, Passthrough, Expected extends Actual> = Passthrough;
type Difference<A, Without> = {
  [P in DiffUnion<keyof A, keyof Without>]: A[P];
}
type DiffUnion<T extends string, U extends string> =
  ({[P in T]: P } &
  { [P in U]: never } &
  { [k: string]: never })[T];

参照：遊び場。

良いですね！ @gcanti （ typelevel-ts ）と@pelotom （ type-zoo ）も興味があるかもしれません。 :)

興味のある人なら誰でも、関数パラメーターに正確な型を適用する簡単な方法を見つけました。 少なくともTS2.7で動作します。

function myFn<T extends {[K in keyof U]: any}, U extends DesiredType>(arg: T & U): void;

編集：これが機能するためには、引数にオブジェクトリテラルを直接指定する必要があると思います。 上記で別のconstを宣言し、代わりにそれを渡すと、これは機能しません。 ：/ただし、回避策の1つは、呼び出しサイトでオブジェクトスプレッドを使用することです。つまり、 myFn({...arg})です。

編集：申し訳ありませんが、TS2.7のみについて言及していることを読みませんでした。 そこでテストします！

@vaskevich動作させることができないようです。つまり、 colourを過剰なプロパティとして検出していません。

条件型が着地すると（＃21316）、「新鮮でない」オブジェクトリテラルの場合でも、関数パラメーターとして正確な型を要求するために次のことを行うことができます。

type Exactify<T, X extends T> = T & {
    [K in keyof X]: K extends keyof T ? X[K] : never
}

type Foo = {a?: string, b: number}

declare function requireExact<X extends Exactify<Foo, X>>(x: X): void;

const exact = {b: 1}; 
requireExact(exact); // okay

const inexact = {a: "hey", b: 3, c: 123}; 
requireExact(inexact);  // error
// Types of property 'c' are incompatible.
// Type 'number' is not assignable to type 'never'.

もちろん、タイプを広げると機能しませんが、それについて実際にできることは何もないと思います。

const inexact = {a: "hey", b: 3, c: 123} as Foo;
requireExact(inexact);  // okay

考え？

関数パラメーターが進歩しているようです。 関数の戻り値に正確な型を適用する方法を見つけた人はいますか？

@jezzgoodwinは実際にはそうではありません。 関数の戻り値の根本的な原因である＃241を参照してください。これは、追加のプロパティが適切にチェックされていないためです。

もう1つのユースケース。 エラーとして報告されていない次の状況が原因で、バグが発生しそうになりました。

interface A {
    field: string;
}

interface B {
    field2: string;
    field3?: string;
}

type AorB = A | B;

const fixture: AorB[] = [
    {
        field: 'sfasdf',
        field3: 'asd' // ok?!
    },
];

（遊び場）

これに対する明らかな解決策は次のとおりです。

type AorB = Exact<A> | Exact<B>;

＃16679で提案された回避策を見ましたが、私の場合、タイプはAorBorC （大きくなる可能性があります）であり、各オブジェクトには複数のプロパティがあるため、 fieldX?:neverプロパティのセットを手動で計算するのはかなり難しいですタイプごとに。

@michalstockiそれは＃

とにかく、正確な型がなく、共用体に厳密な過剰なプロパティチェックがない場合は、条件付き型を使用して手動ではなく、プログラムでこれらのfieldX?:neverプロパティを実行できます。

type AllKeys<U> = U extends any ? keyof U : never
type ExclusifyUnion<U> = [U] extends [infer V] ?
 V extends any ? 
 (V & {[P in Exclude<AllKeys<U>, keyof V>]?: never}) 
 : never : never

そして、あなたの組合を次のように定義します

type AorB = ExclusifyUnion<A | B>;

に拡大します

type AorB = (A & {
    field2?: undefined;
    field3?: undefined;
}) | (B & {
    field?: undefined;
})

自動的。 どのAorBorCでも機能します。

排他的論理和または実装については、 https： //github.com/Microsoft/TypeScript/issues/14094#issuecomment-373780463も参照して

@jcalz高度なタイプのExclusifyUnionはあまり安全ではありません：

const { ...fields } = o as AorB;

fields.field3.toUpperCase(); // it shouldn't be passed

fieldsのフィールドはすべてオプションではありません。

これはExact型とはあまり関係がないと思いますが、共用体型のオブジェクトを広げて構造を解除するとどうなるかと関係があります。 ユニオンは、オブジェクトを個々のプロパティに引き離してから再結合するため、フラット化されて単一の交差点のようなタイプになります。 各組合の構成要素間の相関関係や制約は失われます。 回避方法がわからない...バグの場合は、別の問題である可能性があります。

明らかに、破壊する前にタイプガードを行うと、状況はより良く動作します。

declare function isA(x: any): x is A;
declare function isB(x: any): x is B;

declare const o: AorB;
if (isA(o)) {
  const { ...fields } = o;
  fields.field3.toUpperCase(); // error
} else {
  const { ...fields } = o;
  fields.field3.toUpperCase(); // error
  if (fields.field3) {
    fields.field3.toUpperCase(); // okay
  }
}

これがあなたが見ている問題を「修正」するというわけではありませんが、それは私が誰かが制約された組合で行動することを期待する方法です。

たぶんhttps://github.com/Microsoft/TypeScript/pull/24897はスプレッドの問題を修正し

私はパーティーに遅れるかもしれませんが、少なくともあなたのタイプが完全に一致することを確認する方法は次のとおりです。

type AreSame<A, B> = A extends B
    ? B extends A ? true : false
    : false;
const sureIsTrue: (fact: true) => void = () => {};
const sureIsFalse: (fact: false) => void = () => {};



declare const x: string;
declare const y: number;
declare const xAndYAreOfTheSameType: AreSame<typeof x, typeof y>;
sureIsFalse(xAndYAreOfTheSameType);  // <-- no problem, as expected
sureIsTrue(xAndYAreOfTheSameType);  // <-- problem, as expected

私がこれを行うことができればいいのに：

type Exact<A, B> = A extends B ? B extends A ? B : never : never;
declare function needExactA<X extends Exact<A, X>>(value: X): void;

この問題で説明されている機能は、空の/インデックス付きのインターフェイスが関数やクラスなどのオブジェクトのような型と一致する場合に役立ちますか？

interface MyType
{
    [propName: string]: any;
}

function test(value: MyType) {}

test({});           // OK
test(1);            // Fails, OK!
test('');           // Fails, OK!
test(() => {});     // Does not fail, not OK!
test(console.log);  // Does not fail, not OK!
test(console);      // Does not fail, not OK!

インターフェイスMyTypeは、インデックスシグネチャのみを定義し、関数testの唯一のパラメータのタイプとして使用されます。 タイプの関数に渡されるパラメーター：

• オブジェクトリテラル{} 、合格。 予想される行動。
• 数値定数1は渡されません。 予想される動作（タイプ「1」の_引数はタイプ「MyType」のパラメーターに割り当てることができません。_）
• 文字列リテラル''は渡されません。 予期される動作（_`タイプ '""'の引数はタイプ 'MyType'のパラメーターに割り当てることができません。_）
• 矢印関数宣言() => {} ：合格。 予期しない動作。 関数はオブジェクトなので、おそらく合格ですか？
• クラスメソッドconsole.logパス。 予期しない動作。 矢印関数に似ています。
• クラスconsoleが合格します。 予期しない動作。 おそらくクラスはオブジェクトだからですか？

重要なのは、インターフェースMyType完全に一致する変数のみを、そのタイプである（暗黙的に変換されていない）ことによってのみ許可することです。 TypeScriptは署名に基づいて多くの暗黙的な変換を行うように思われるため、これはサポートできないものである可能性があります。

これがトピックから外れている場合はお詫びします。 これまでのところ、この問題は私が上で説明した問題に最も近いものです。

@ Janne252この提案は間接的にあなたを助けることができます。 明らかなExact<{[key: string]: any}>を試したとすると、それが機能する理由は次のとおりです。

• オブジェクトリテラルは、すでに{[key: string]: any}行っているように、期待どおりに渡されます。
• リテラルは{[key: string]: any}割り当てられないため、数値定数は期待どおりに失敗します。
• 文字列リテラルは{[key: string]: any}割り当てられないため、期待どおりに失敗します。
• 関数とクラスコンストラクターは、 callシグネチャ（文字列プロパティではない）が原因で失敗します。
• consoleオブジェクトは、それがオブジェクト（クラスではない）であるために渡されtypeofは、いくつかのパラメーターや型エイリアスを追加するための単なる砂糖です。見た目ほど魔法ではありません。

@blakeembrey @michalstocki @ aleksey-bykov
これは正確なタイプを行う私の方法です：

type Exact<A extends object> = A & {__kind: keyof A};

type Foo = Exact<{foo: number}>;
type FooGoo = Exact<{foo: number, goo: number}>;

const takeFoo = (foo: Foo): Foo => foo;

const foo = {foo: 1} as Foo;
const fooGoo = {foo: 1, goo: 2} as FooGoo;

takeFoo(foo)
takeFoo(fooGoo) // error "[ts]
//Argument of type 'Exact<{ foo: number; goo: number; }>' is not assignable to parameter of type 'Exact<{ //foo: number; }>'.
//  Type 'Exact<{ foo: number; goo: number; }>' is not assignable to type '{ __kind: "foo"; }'.
//    Types of property '__kind' are incompatible.
//      Type '"foo" | "goo"' is not assignable to type '"foo"'.
//        Type '"goo"' is not assignable to type '"foo"'."

const takeFooGoo = (fooGoo: FooGoo): FooGoo => fooGoo;

takeFooGoo(fooGoo);
takeFooGoo(foo); // error "[ts]
// Argument of type 'Exact<{ foo: number; }>' is not assignable to parameter of type 'Exact<{ foo: number; // goo: number; }>'.
//  Type 'Exact<{ foo: number; }>' is not assignable to type '{ foo: number; goo: number; }'.
//    Property 'goo' is missing in type 'Exact<{ foo: number; }>'.

これは、関数のパラメーター、戻り値、さらには割り当てに対しても機能します。
const foo: Foo = fooGoo; //エラー
実行時のオーバーヘッドはありません。 唯一の問題は、新しい正確なオブジェクトを作成するときはいつでも、その型に対してキャストする必要があるということですが、それは実際には大したことではありません。

元の例の動作は正しいと思います。 interfaceが開いていると思います。 対照的に、私はtypeが閉じられることを期待しています（そしてそれらは時々閉じMappedOmitタイプを作成するときの驚くべき動作の例を次に示します。
https://gist.github.com/donabrams/b849927f5a0160081db913e3d52cc7b3

この例のMappedOmitタイプは、識別された共用体を対象とした場合にのみ機能します。 区別されていない共用体の場合、共用体内の型の共通部分が渡されると、Typescript3.2が渡されます。

as TypeXまたはas anyを使用してキャストする上記の回避策には、構築のエラーを隠すという副作用があります。 タイプチェッカーが構築のエラーをキャッチするのにも役立つことを望んでいます！ さらに、明確に定義された型から静的に生成できるものがいくつかあります。 上記のような回避策（またはここで説明されている名目上のタイプの回避策：https：//gist.github.com/donabrams/74075e89d10db446005abe7b1e7d9481）は、これらのジェネレーターが機能しないようにします（ただし、 _先行フィールドをフィルター処理することはできますが、これは面倒な慣習ですそれは絶対に避けられます）。

@ aleksey-bykov fyiあなたの実装はそこまでの99％だと思いますが、これは私にとってはうまくいきました：

type AreSame<A, B> = A extends B
    ? B extends A ? true : false
    : false;
type Exact<A, B> = AreSame<A, B> extends true ? B : never;

const value1 = {};
const value2 = {a:1};

// works
const exactValue1: Exact<{}, typeof value1> = value1;
const exactValue1WithTypeof: Exact<typeof value1, typeof value1> = value1;

// cannot assign {a:number} to never
const exactValue1Fail: Exact<{}, typeof value2> = value2;
const exactValue1FailWithTypeof: Exact<typeof value1, typeof value2> = value2;

// cannot assign {} to never
const exactValue2Fail: Exact<{a: number}, typeof value1> = value1;
const exactValue2FailWithTypeof: Exact<typeof value2, typeof value1> = value1;

// works
const exactValue2: Exact<{a: number}, typeof value2> = value2;
const exactValue2WithTypeof: Exact<typeof value2, typeof value2> = value2;

うわー、ここに花を残してください、プレゼントはそのビンに入れます

ここで行うことができる1つの小さな改善：
次のExact定義を使用すると、すべてのB Aおよびneverタイプとして、 AからB減算が効果的に作成されます。 Bの一意のキーを使用すると、無効なプロパティでより詳細なエラーが発生する可能性があります。

type Omit<T, K> = Pick<T, Exclude<keyof T, keyof K>>;
type Exact<A, B = {}> = A & Record<keyof Omit<B, A>, never>;

最後に、2番目のBテンプレート引数の明示的なテンプレート使用法を追加せずにこれを実行できるようにしたかったのです。 メソッドでラップすることでこの作業を行うことができました。ランタイムに影響するため理想的ではありませんが、本当に必要な場合に役立ちます。

function makeExactVerifyFn<T>() {
  return <C>(x: C & Exact<T, C>): C => x;
}

使用例：

interface Task {
  title: string;
  due?: Date;
}

const isOnlyTask = makeExactVerifyFn<Task>();

const validTask_1 = isOnlyTask({
    title: 'Get milk',
    due: new Date()  
});

const validTask_2 = isOnlyTask({
    title: 'Get milk'
});

const invalidTask_1 = isOnlyTask({
    title: 5 // [ts] Type 'number' is not assignable to type 'string'.
});

const invalidTask_2 = isOnlyTask({
    title: 'Get milk',
    procrastinate: true // [ts] Type 'true' is not assignable to type 'never'.
});

@danielnmsft例では、特に適切な検証に必要な場合、 Exact<A, B> Bをオプションのままにしておくのは奇妙に思えます。 そうでなければ、それは私にはかなりよく見えます。 ただし、 Equalという名前の方が見栄えがします。

@drabinowitzタイプExactは実際にはここで提案されたものを表していないため、おそらくAreExactような名前に変更する必要があります。 つまり、自分のタイプではこれを行うことはできません。

function takesExactFoo<T extends Exact<Foo>>(foo: T) {}

ただし、正確なパラメータタイプを実装するには、タイプが便利です。

type AreSame<A, B> = A extends B
    ? B extends A ? true : false
    : false;
type Exact<A, B> = AreSame<A, B> extends true ? B : never;

interface Foo {
    bar: any
}

function takesExactFoo <T>(foo: T & Exact<Foo, T>) {
                    //  ^ or `T extends Foo` to type-check `foo` inside the function
}

let foo = {bar: 123}
let foo2 = {bar: 123, baz: 123}

takesExactFoo(foo) // ok
takesExactFoo(foo2) // error

UPD1これは、 @ danielnmsftのソリューションのように+1ランタイム関数を作成せず、もちろんはるかに柔軟性があります。

UPD2ダニエルが実際に@drabinowitzと基本的に同じタイプExactを作成したが、よりコンパクトでおそらくより良いタイプであることに

AreSame / Exact定義は、共用体型では機能しないようです。
例： Exact<'a' | 'b', 'a' | 'b'>はneverます。
これは明らかにtype AreSame<A, B> = A|B extends A&B ? true : false;定義することで修正できます

@nerumoは、あなたが示したのと同じタイプのレデューサー関数でこれを確実に見つけました。

あなたが持っていたものからいくつかの追加のオプション：

1 typeof 、戻りタイプを入力タイプと同じに設定できます。 非常に複雑なタイプの場合に便利です。 これを見ると、余分なプロパティを防ぐことが目的であることがより明確にわかります。

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>): typeof state {
   return {
       ...state,
       fullName: action.payload        // THIS IS REPORTED AS AN ERROR
   };
}

2レデューサーの場合、一時変数の代わりに、返す前にそれ自体に割り当てます。

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>) {
   return (state = {
       ...state,
       fullName: action.payload        // THIS IS REPORTED AS AN ERROR
   });
}

3本当に一時変数が必要な場合は、明示的な型を指定せずに、もう一度typeof stateします。

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>) {

   const newState: typeof state = {
       ...state,
       fullName: action.payload         // THIS IS REPORTED AS AN ERROR
   };

   return newState;
}

3bレデューサーに...stateが含まれていない場合は、次のタイプにPartial<typeof state>を使用できます。

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>) {

   const newState: Partial<typeof state> = {
       name: 'Simon',
       fullName: action.payload         // THIS IS REPORTED AS AN ERROR
   };

   return newState;
}

私はこの会話全体（そして私はスレッド全体を読んだだけです）がほとんどの人にとって問題の核心を逃したと感じています、そしてそれはエラーを防ぐために私たちが望むのは「より広い」タイプを許可しないことを防ぐためのタイプアサーションです：

これは人々が最初に試みるかもしれないことであり、 'fullName'を禁止しません：

 return <State> {
       ...state,
       fullName: action.payload         // compiles ok :-(
   };

これは、 <Dog> catがコンパイラーに指示しているためです-はい、私が何をしているのかはわかっています、それはDogです！ あなたは許可を求めていません。

したがって、私にとって最も役立つのは、無関係なプロパティを防ぐ、より厳密なバージョンの<Dog> catです。

 return <strict State> {
       ...state,
       fullName: action.payload     // compiles ok :-(
   };

Exact<T>タイプのもの全体には、結果を通じて多くの波紋があります（これは長いスレッドです！）。 それはあなたが望むと思うものである「チェックされた例外」の議論全体を思い出させますが、それは多くの問題を抱えていることがわかります（突然5分後にUnexact<T>欲しいなど）。

一方、 <strict T>は、「不可能な」タイプが「通過」するのを防ぐための障壁のように機能します。 これは基本的に、型を通過する型フィルターです（上記のランタイム関数で行われたように）。

ただし、初心者にとっては、それが不可能な場合に「不正なデータ」が通過するのを防いだと考えるのは簡単です。

したがって、提案構文を作成する必要がある場合は、次のようになります。

/// This syntax is ONLY permitted directly in front of an object declaration:
return <strict State> { ...state, foooooooooooooo: 'who' };

OPに戻る：理論的には^[1]否定型を使用すると、 type Exact<T> = T & not Record<not keyof T, any>書くことができます。 その場合、 Exact<{x: string}>は、 x以外のキーを持つタイプが割り当てられることを禁止します。 ここにいる全員が求めていることを満足させるのに十分かどうかはわかりませんが、OPに完全に適合しているようです。

_{[1]理論的には、それはより優れたインデックス署名にも基づいているためです。}

ここで説明されている問題があるかどうか知りたいです。 私は次のようなコードを持っています：

const Layers = {
  foo: 'foo'
  bar: 'bar'
  baz: 'baz'
}

type Groups = {
  [key in keyof Pick<Layers, 'foo' | 'bar'>]: number
}

const groups = {} as Groups

次に、不明なプロパティを設定できます。これは、私が望まないことです。

groups.foo = 1
groups.bar = 2
groups.anything = 2 // NO ERROR :(

anything設定anyです。 私はそれがエラーになることを望んでいました。

これはこの問題によって解決されるものですか？

結局、私はやるべきだった

type Groups = {
  [key in keyof Pick<typeof Layers, 'foo' | 'bar'>]: number
}

typeofの追加使用に注意してください。

Atomプラグインatom-typescriptは失敗しないように一生懸命努力し、最終的にクラッシュしました。 typeofを追加すると、通常の状態に戻り、未知の小道具は許可されなくなりました。これは私が期待していたことです。

言い換えると、 typeofを使用していないとき、 atom-typescriptは、タイプGroupsのオブジェクトを使用していたコードの他の場所で、タイプを把握しようとしていました。それは私が未知の小道具を追加することを可能にし、それらのためにanyタイプヒントを見せてくれました。

したがって、このスレッドの問題はないと思います。

もう1つの問題は、オプションのプロパティの処理方法です。

オプションのプロパティを持つタイプがある場合、それらのプロパティのExact<T>はどういう意味ですか？

export type PlaceOrderResponse = { 
   status: 'success' | 'paymentFailed', 
   orderNumber: string
   amountCharged?: number
};

Exact<T>は、すべてのオプションのプロパティを定義する必要があることを意味しますか？ あなたはそれを何と指定しますか？ 'undefined'または 'null'ではありません。これは実行時の影響があるためです。

これには、「必須のオプションパラメータ」を指定する新しい方法が必要ですか？

たとえば、次のコードサンプルでamountChargedを割り当てて、型の「正確さ」を満たすために何を割り当てる必要がありますか？ どういうわけか、このプロパティを少なくとも「承認」するように強制しないと、「正確」ではありません。 <never>ですか？ undefinedまたはnullにすることはできません。

const exactOrderResponse: Exact<PlaceOrderResponse> = 
{
   status: 'paymentFailed',
   orderNumber: '1001',
   amountCharged: ????      
};

ですから、あなたは考えているかもしれません-それはまだオプションであり、今では完全にオプションであり、これは単にます。 そして確かに実行時に設定する必要はありませんが、疑問符を付けてExact<T> 「壊した」ように見えます。

このチェックを行う必要があるのは、2つのタイプ間で値を割り当てる場合だけでしょうか。 （両方にamountCharged?: number含まれるようにするため）

ここで、ダイアログボックスの入力データの新しいタイプを紹介しましょう。

export type OrderDialogBoxData = { 
   status: 'success' | 'paymentFailed', 
   orderNumber: string
   amountCharge?: number      // note the typo here!
};

では、これを試してみましょう。

// run the API call and then assign it to a dialog box.
const serverResponse: Exact<PlaceOrderResponse> = await placeOrder();
const dialogBoxData: Exact<OrderDialogBoxData> = serverResponse;    // SHOULD FAIL

もちろん、タイプミスのためにこれが失敗することを期待します-このプロパティは両方でオプションですが。

それで、私は「なぜ私たちはそもそもこれが欲しいのですか？」に戻りました
私はそれがこれらの理由（または状況に応じてサブセット）のためだと思います：

• プロパティ名のタイプミスを避ける
• 'コンポーネント'にプロパティを追加する場合、それを使用するすべてのものがそのプロパティも追加する必要があることを確認する必要があります
• 'コンポーネント'からプロパティを削除する場合は、どこでも削除する必要があります。
• 不必要に余分なプロパティを提供しないようにしてください（おそらく、APIに送信していて、ペイロードを無駄のない状態に保ちたいと考えています）

「正確なオプションのプロパティ」が適切に処理されない場合、これらの利点のいくつかは壊れているか、非常に混乱しています！

また、上記の例では、タイプミスを回避するためにExactを「シューホーン」しましたが、大きな混乱を引き起こすことに成功しただけです。 そして、今ではかつてないほどもろくなっています。

私がよく必要とするのは、実際にはExact<T>タイプではなく、次の2つのうちの1つだと思います。

NothingMoreThan<T>または
NothingLessThan<T>

「必須のオプション」が問題になりました。 1つ目は、割り当てのRHSで余分なものを定義することを許可せず、2つ目は、すべて（オプションのプロパティを含む）が割り当てのRHSで指定されていることを確認します。

NothingMoreThanは、ネットワークを介して送信されるペイロード、またはJSON.stringify()に役立ちます。また、RHSのプロパティが多すぎるためにエラーが発生した場合は、ランタイムコードを記述して選択する必要があります。必要なプロパティ。 そして、それが正しい解決策です-それがJavascriptの仕組みだからです。

NothingLessThanは、オプションの(optional?: number)プロパティを考慮する必要があることを除いて、すべての通常の割り当てについて、typescriptにすでにあるものの一種です。

これらの名前が魅力になるとは思いませんが、概念はExact<T>よりも明確で詳細だと思います...

次に、おそらく（本当に必要な場合）：

Exact<T> = NothingMoreThan<NothingLessThan<T>>;

またはそれは次のようになります：

Exact<T> = NothingLessThan<NothingMoreThan<T>>;   // !!

この投稿は、いくつかのオプションのプロパティを含む「ダイアログボックスデータ型」があり、サーバーからのデータが割り当て可能であることを確認したいという、今日私が抱えている実際の問題の結果です。

最後の注意： NothingLessThan / NothingMoreThanは、タイプAがタイプBから拡張されている、またはBがAから拡張されている、上記のコメントのいくつかと同様の「感触」を持っています。オプションのプロパティには対応していません（少なくとも、今日は対応できないと思います）。

@simeyla 「それ以上のものはない」バリアントで

• 「以上」は普通のタイプです。 TSはこれを暗黙的に行い、すべてのタイプはfor all T extends X: Tと同等として扱われます。
• 「これ以上」は基本的に反対です。暗黙のfor all T super X: T

一方または両方を明示的に選択する方法で十分です。 副作用として、JavaのT super Cを提案されたT extends NothingMoreThan<C>として指定できます。 ですから、これはおそらく標準の正確なタイプよりも

しかし、これは構文であるべきだと思います。 多分これ？

• extends T -Tに割り当て可能なすべてのタイプの和集合。つまり、単なるTと同等です。
• super T -Tが割り当て可能なすべてのタイプの和集合。
• extends super T 、 super extends T -Tに相当するすべての型の和集合。これは、型のみを割り当て可能であり、それ自体に割り当てることができるため、グリッドから外れます。
• type Exact<T> = extends super T -読みやすくするために、上記の一般的なケースに組み込まれたSugar。
• これは割り当て可能性を切り替えるだけなので、正確なタイプまたはスーパータイプのユニオンなどを使用できます。

これにより、 Exact<{a: number}> | Exact<{b: number}>ように、各バリアントをExact<T>にするだけで、ユーザーランドに＃14094を実装することもできます。

これにより、ユーザーランドでも否定型が可能になるのではないかと思います。 私はそれが正しいと信じていますが、それを確認するために最初にいくつかの複雑な型の算術演算を行う必要があり、それを証明することは正確に明白なことではありません。

（super T）|なので、これによってユーザーランドでも否定型が可能になるのではないかと思います。 （Tを拡張）unknownと同等です。 そうだと思いますが、それを確認するために最初に複雑な型の算術演算を行う必要があり、それを証明するのは必ずしも明白なことではありません。

(super T) | (extends T) === unknownが割り当て可能性を保持するには、全順序である必要があります。

@ jack-williams良いキャッチと修正（クレームを削除することにより）。 少し遊んでいたときに、最初はうまくいかなかったのはなぜだろうと思っていました。

@ jack-williams

「以上」は普通のタイプです。 TSはこれを暗黙的に行い、すべてのタイプが同等として扱われます

はいといいえ。 しかし、ほとんどはそうです... ...ただし、 strictモードの場合のみです。

そのため、プロパティを論理的に「オプション」にする必要がある状況がたくさんありましたが、コンパイラに「忘れた」かスペルを間違えたかを教えてもらいたいと思いました。

それはまさにlastName: string | undefined得られるものですが、私はほとんどlastName?: stringを持っていました。もちろん、 strictモードがないと、すべての不一致について警告されることはありません。

私は常に厳密モードについて知っていました、そして私は昨日までそれをオンにしなかった正当な理由を見つけることができません-しかし今私は持っています（そして私はまだ何百もの修正を歩いています）私が望んでいた動作を「箱から出して」取得する方がはるかに簡単です。

Required<A> extends Required<B>で遊んだり、オプションの?プロパティフラグを削除したりするなど、必要なものを取得するためにあらゆる種類のことを試みていました。 それは私にまったく別のうさぎの穴を下ろしました-（そしてこれは私がstrictモードをオンにする前のすべて

重要なのは、今日「正確な」タイプに近いものを取得しようとしている場合は、 strictモード（またはフラグの任意の組み合わせで適切なチェックが行われる）を有効にすることから始める必要があるということです。 そして、後でmiddleName: string | undefinedを追加する必要がある場合は、ブームになります。「検討する」必要のある場所が突然見つかります:-)

PS。 コメントありがとうございます-とても役に立ちました。 明らかにstrictモードを使用していないコードがたくさんあることに気づきました。そうすると、私のように人々が壁にぶつかります。 その使用をもっと奨励するために何ができるのだろうか？

@simeylaフィードバックと感謝は@isiahmeadowsに向けるべきだと思います！

基本的なプロトタイプを実装した後、Exactタイプの経験を書き留めると思いました。 私の一般的な考えは、チームは彼らの評価に的を絞っていたということです。

私たちの希望する診断は、これが、比較的少数の真に閉じたAPIの外では、XY問題の解決策であるということです。

さらに別のオブジェクトタイプを導入するコストが、より多くのエラーをキャッチしたり、新しいタイプの関係を有効にしたりすることによって返済されるとは思いません。 最終的に、正確な型は私に_say_をもっとさせてくれましたが、彼らは私に_do_をもっとさせませんでした。

正確なタイプの潜在的なユースケースのいくつかを調べる：

keysとfor ... in強い型付け。

キーを列挙するときに、より正確なタイプを使用することは魅力的ですが、実際には、概念的に正確なもののキーを列挙することに気づきませんでした。 キーを正確に知っている場合は、直接アドレス指定してみませんか？

オプションのプロパティの拡大を強化します。

左側のタイプには、エイリアス化された互換性のないxプロパティが含まれている可能性があるため、割り当て可能性ルール{ ... } <: { ...; x?: T }は適切ではありません。 正確なタイプから割り当てる場合、このルールは適切になります。 実際には、私はこのルールを使用しません。 そもそも正確なタイプを持たないレガシーシステムに適しているようです。

ReactとHOC

私は、小道具の通過を改善する正確なタイプと、スプレッドタイプの簡素化に私の最後の希望を固定しました。 現実には、正確な型は有界ポリモーフィズムのアンチテーゼであり、基本的に非構成的です。

有界ジェネリックを使用すると、気になる小道具を指定し、残りを通過させることができます。 境界が正確になるとすぐに、幅のサブタイプが完全に失われ、ジェネリックの有用性が大幅に低下します。 もう1つの問題は、TypeScriptの構成の主要なツールの1つが交差ですが、交差タイプは正確なタイプと互換性がないことです。 正確なコンポーネントを持つ重要な交差型は空虚になります。_正確な型は構成されません_。 reactとpropsの場合、おそらく行タイプと行多相が必要ですが、それは別の日です。

正確な型によって解決される可能性のあるほとんどすべての興味深いバグは、過剰なプロパティチェックによって解決されます。 最大の問題は、過剰なプロパティチェックが判別プロパティのない組合では機能しないことです。 これを解決すると、正確なタイプに関連する興味深い問題のほとんどすべてがなくなります、IMO。

@ jack-williams正確なタイプを持つことは一般的にあまり有用ではないことに同意します。 過剰なプロパティチェックの概念は、実際には私のsuper T演算子の提案でカバーされいないためです。

私は個人的に離れて多分からこれを支持して重くないんだけどT super U私が今まで過剰プロパティ・チェックに遭遇した唯一のユースケースについて、壊れたサーバを扱ったことから、*あなたが通常で回避できるものラッパー関数を使用してリクエストを手動で生成し、余分なゴミを取り除きます。 このスレッドでこれまでに報告された他のすべての問題は、単純な識別された共用体を使用するだけで解決できます。

*これは基本的に私の提案を使用するとT extends super U -下限は反変のジェネリック型を制約するのに役立つことがあり、回避策は通常私の経験で多くの余分な型の定型文を導入することになります。

@isiahmeadows確かに、下限の型が役立つ可能性があることに同意します。それから正確な型を取得できれば、それを使用したい人にとっては

@ jack-williams私が主に過剰なプロパティチェックの正確なタイプと関連部分を参照していたという私のニュアンスを見逃したと思います。 下限の型についてのビットは、理由のための脚注でした-それは接線方向にのみ関連する余談でした。

私は、さまざまな程度の正確さを必要とする関数の引数に対して機能するこの実装をなんとか作成しました。

// Checks that B is a subset of A (no extra properties)
type Subset<A extends {}, B extends {}> = {
   [P in keyof B]: P extends keyof A ? (B[P] extends A[P] | undefined ? A[P] : never) : never;
}

// This can be used to implement partially strict typing e.g.:
// ('b?:' is where the behaviour differs with optional b)
type BaseOptions = { a: string, b: number }

// Checks there are no extra properties (Not More, Less fine)
const noMore = <T extends Subset<BaseOptions, T>>(options: T) => { }
noMore({ a: "hi", b: 4 })        //Fine
noMore({ a: 5, b: 4 })           //Error 
noMore({ a: "o", b: "hello" })   //Error
noMore({ a: "o" })               //Fine
noMore({ b: 4 })                 //Fine
noMore({ a: "o", b: 4, c: 5 })   //Error

// Checks there are not less properties (More fine, Not Less)
const noLess = <T extends Subset<T, BaseOptions>>(options: T) => { }
noLess({ a: "hi", b: 4 })        //Fine
noLess({ a: 5, b: 4 })           //Error
noLess({ a: "o", b: "hello" })   //Error
noLess({ a: "o" })               //Error  |b?: Fine
noLess({ b: 4 })                 //Error
noLess({ a: "o", b: 4, c: 5 })   //Fine

// We can use these together to get a fully strict type (Not More, Not Less)
type Strict<A extends {}, B extends {}> = Subset<A, B> & Subset<B, A>;
const strict = <T extends Strict<BaseOptions, T>>(options: T) => { }
strict({ a: "hi", b: 4 })        //Fine
strict({ a: 5, b: 4 })           //Error
strict({ a: "o", b: "hello" })   //Error
strict({ a: "o" })               //Error  |b?: Fine
strict({ b: 4 })                 //Error
strict({ a: "o", b: 4, c: 5 })   //Error

// Or a fully permissive type (More Fine, Less Fine)
type Permissive<A extends {}, B extends {}> = Subset<A, B> | Subset<B, A>;
const permissive = <T extends Permissive<BaseOptions, T>>(options: T) => { }
permissive({ a: "hi", b: 4 })        //Fine
permissive({ a: 5, b: 4 })           //Error
permissive({ a: "o", b: "hello" })   //Error
permissive({ a: "o" })               //Fine
permissive({ b: 4 })                 //Fine
permissive({ a: "o", b: 4, c: 5 })   //Fine

// This is a little unweildy, there's also a shortform that works in many cases:
type Exact<A extends {}> = Subset<A, A>
// The simpler Exact type works for variable typing
const options0: Exact<BaseOptions> = { a: "hi", b: 4 }        //Fine
const options1: Exact<BaseOptions> = { a: 5, b: 4 }           //Error
const options2: Exact<BaseOptions> = { a: "o", b: "hello" }   //Error
const options3: Exact<BaseOptions> = { a: "o" }               //Error |b?: Fine
const options4: Exact<BaseOptions> = { b: 4 }                 //Error
const options5: Exact<BaseOptions> = { a: "o", b: 4, c: 5 }   //Error

// It also works for function typing when using an inline value
const exact = (options: Exact<BaseOptions>) => { }
exact({ a: "hi", b: 4 })        //Fine
exact({ a: 5, b: 4 })           //Error
exact({ a: "o", b: "hello" })   //Error
exact({ a: "o" })               //Error  |b?: Fine
exact({ b: 4 })                 //Error
exact({ a: "o", b: 4, c: 5 })   //Error

// But not when using a variable as an argument even of the same type
const options6 = { a: "hi", b: 4 }
const options7 = { a: 5, b: 4 }
const options8 = { a: "o", b: "hello" }
const options9 = { a: "o" }
const options10 = { b: 4 }
const options11 = { a: "o", b: 4, c: 5 }
exact(options6)                 //Fine
exact(options7)                 //Error
exact(options8)                 //Error
exact(options9)                 //Error |b?: Fine
exact(options10)                //Error
exact(options11)                //Fine  -- Should not be Fine

// However using strict does work for that
// const strict = <T extends Strict<BaseOptions, T>>(options: T) => { }
strict(options6)                //Fine
strict(options7)                //Error
strict(options8)                //Error
strict(options9)                //Error |b?: Fine
strict(options10)               //Error
strict(options11)               //Error -- Is correctly Error

見る

https://www.npmjs.com/package/ts-strictargs
https://github.com/Kotarski/ts-strictargs

Reactコンポーネントをラップするときに、これのユースケースがあるように感じます。そこでは、小道具を「パススルー」する必要があります： //github.com/Microsoft/TypeScript/issues/29883。 @ jack-williamsこれについて何か考えはありますか？

@OliverJAsh関連性があるように見えますが、Reactについてもほとんど知らないことを認めなければなりません。 ここで正確な型がどのように正確に役立つかを調べることが役立つと思います。

type MyComponentProps = { foo: 1 };
declare const MyComponent: ComponentType<MyComponentProps>;

type MyWrapperComponent = MyComponentProps & { myWrapperProp: 1 };
const MyWrapperComponent: ComponentType<MyWrapperComponent> = props => (
    <MyComponent
        // We're passing too many props here, but no error!
        {...props}
    />
);

私が何か間違ったことを言ったときはいつでも私を訂正してください。

正確なタイプを受け入れるためにMyComponentを指定することが最初だと思いますか？

declare const MyComponent: ComponentType<Exact<MyComponentProps>>;

その場合、エラーが発生しますが、どのようにエラーを修正しますか？ ここでは、ラッパーコンポーネントがずっと同じプロップタイプを持っているだけではなく、ある時点でプロップサブセットを動的に抽出する必要があると想定しています。 これは合理的な仮定ですか？

MyWrapperComponent小道具も正確であれば、破壊的なバインドを行うだけで十分だと思います。 一般的なケースでは、これには正確な型よりもOmit型が必要であり、私はそこでのセマンティクスを本当に知りません。 準同型の写像型のように機能し、正確さを保持できると思いますが、これにはもっと検討が必要だと思います。

MyWrapperComponentが正確でない場合は、新しいタイプの正確さを証明するために実行時チェックが必要になります。これは、必要なプロパティを明示的に選択することによってのみ実行できます（これは、あなたのOP）。 この場合、どれだけ稼げるかわかりません。

propsが一般的な型であり、 { ...props1, ...props2 }ような小道具を組み合わせる必要がある一般的なケースである可能性がどれほどあるかわからないため、私がカバーしなかったもの。 これは一般的ですか？

@Kotarski万が一NPMレジストリに公開しましたか？

@gitowiec

@Kotarski万が一NPMレジストリに公開しましたか？

https://www.npmjs.com/package/ts-strictargs
https://github.com/Kotarski/ts-strictargs

私はこのユースケースを持っています：

type AB = { a: string, b: string }
type CD = { c: string, d: string }
type ABCD = AB & CD

// I want this to error, because the 'c' should mean it prevents either AB or ABCD from being satisfied.
const foo: AB | ABCD = { a, b, c };

// I presume that I would need to do this:
const foo: Exact<AB> | Exact<ABCD> = { a, b, c };

@ ryami333正確なタイプは必要ありません。 過剰なプロパティチェックを修正する必要があります：＃13813。

@ ryami333追加の型を使用する場合は、必要な処理を実行する型があります。つまり、より厳密なバージョンの共用体を強制します。

type AB = { a: string, b: string }
type CD = { c: string, d: string }
type ABCD = AB & CD


type UnionKeys<T> = T extends any ? keyof T : never;
type StrictUnionHelper<T, TAll> = T extends any ? T & Partial<Record<Exclude<UnionKeys<TAll>, keyof T>, never>> : never;
type StrictUnion<T> = StrictUnionHelper<T, T>

// Error now.
const foo: StrictUnion<AB | ABCD> = { a: "", b: "", c: "" };

@dragomirtitian魅力的です。 なぜ私には興味があります

type KeyofV1<T extends object> = keyof T

とは異なる結果を生成します

type KeyofV2<T> = T extends object ? keyof T : never

誰かが私にこれを説明できますか？

type AB = { a: string, b: string }
type CD = { c: string, d: string }
type ABCD = AB & CD

KeyofV1< AB | ABCD > // 'a' | 'b'
KeyofV2< AB | ABCD > // 'a' | 'b' | 'c' | 'e'

V1はユニオンの共通キーを取得し、 V2は各ユニオンメンバーのキーを取得し、結果をユニオンします。

@weswigham異なる結果を返す必要がある理由はありますか？

はい？ 私が言ったように- V1はすべての組合員に_共通の鍵_を取得します。なぜならkeyofへの引数はkeyof (AB | ABCD) 、これは"A" | "B"にすぎないkeyof AB | keyof ABCDます。

@weswighamでは、条件付きは、暗黙のループを介したように、このように評価しますか？

type Union =
    (AB extends object ? keyof AB : never) |
    (ABCD extends object ? keyof ABCD : never)

私はそのコードを読んでいるとき、私は通常、期待(AB | ABCD) extends object 、単一ユニットとして動作するように確認することを確認する(AB | ABCD)に割り当て可能であるobject 、それが戻ってkeyof (AB | ABCD)ユニットとしての'a' | 'b' 。 暗黙のマッピングは私には本当に奇妙に思えます。

@isiahmeadows分散条件型は、ユニオンのforeachとして見ることができます。 条件型を和集合の各メンバーに順番に適用し、結果は各部分結果の和集合になります。

つまり、 UnionKeys<A | B> = UnionKeys<A> | UnionKeys<B> =(keyof A) | (keyof B)

ただし、条件型が配布される場合にのみ、テストされた型がネイキッド型パラメーターである場合にのみ配布されます。 そう：

type A<T> = T extends object ? keyof T : never // distributive
type B<T> = [T] extends [object] ? keyof T : never // non distributive the type parameter is not naked
type B<T> = object extends T ? keyof T : never // non distributive the type parameter is not the tested type

みんなありがとう、私はそれを手に入れたと思います。 私は理解のためにそれを再配置しました。 NegativeUncommonKeysはそれ自体でも役立つと思います。 これは、他の人にも役立つ場合に備えています。

type UnionKeys<T> = T extends any ? keyof T : never;
type NegateUncommonKeys<T, TAll> = (
    Partial<
        Record<
            Exclude<
                UnionKeys<TAll>,
                keyof T
            >,
            never
        >
    >
) 

type StrictUnion<T, TAll = T> = T extends any 
  ? T & NegateUncommonKeys<T, TAll>
  : never;

TとTAll両方が存在する理由も理解しています。 Tがテストされて裸になる「ループ効果」は、 Tのユニオン内の各アイテムが適用されるのに対し、テストされていないTAllにはすべてのアイテムの元の完全なユニオンが含まれることを意味します。

これは、分配条件型に関するハンドブックセグメントです。

@weswighamうん..セクションは、あるコンパイラエンジニアが別のコンパイラエンジニアのために書いたように読めると思う以外は。

チェックされた型がネイキッド型パラメーターである条件型は、分配条件型と呼ばれます。

ネイキッドタイプのパラメータとは何ですか？ （そしてなぜ彼らはいくつかの服を着ないのですか😄）

つまり、Tは、条件型が共用体型に分散された後の個々の構成要素を指します）

ちょうど昨日、この特定の文が何を意味するのか、そしてなぜ「後」という言葉が強調されたのかについて話し合いました。

ドキュメントは、ユーザーが常に持っているとは限らない事前の知識と用語を想定して書かれていると思います。

ハンドブックのセクションは私には理にかなっており、それをはるかによく説明していますが、それでも私はそこでのデザインの選択に懐疑的です。 設定された理論的および型理論的観点から、その振る舞いが自然にどのように続くかは、私には論理的に意味がありません。 それはちょっとハックすぎるように出くわします。

集合理論的および型理論的観点から自然に従う

セット内の各アイテムを取得し、述語に従ってパーティション化します。

それは分配操作です！

セット内の各アイテムを取得し、述語に従ってパーティション化します。

それは、圏論のようにひどく聞こえ始める集合の集合（つまり、共用体型）について話しているときにのみ意味があります。

@RyanCavanaughわかりました。はっきりさせておきます。私は、 T extends U ? F<T> : G<T>をT <: U ⊢ F(T), (T <: U ⊢ ⊥) ⊢ G(T)として直感的に読み、比較は区分的にではなく、完全なステップとして行いました。 これは、「すべての{if t ∈ U then F({t}) else G({t}) | t ∈ T}の和集合」とは明らかに異なります。これは、現在のセマンティクスです。

（私の構文が少しずれている場合はご容赦ください。私の型理論の知識は完全に独学であるため、すべての構文形式を知っているわけではありません。）

どちらの操作がより直感的であるかは無限の議論の余地がありますが、現在のルールでは、 [T] extends [C]を使用して分配型を非分配にするのは簡単です。 デフォルトが非分配であった場合、分配を引き起こすために別のレベルでいくつかの新しい呪文が必要になります。 これは、行動がより頻繁に好まれる別の質問でもあります。 IME非配布タイプはほとんど必要ありません。

構文操作であるため、配布の強力な理論的根拠はありません。

現実には、それは非常に便利であり、他の方法でエンコードしようとすると苦痛になります。

現状では、会話をトピックから遠ざける前に、先に進んで立ち去ります。

分散性についてはすでに多くの問題がありますが、新しい構文が必要になることに直面しないのはなぜですか？

30572

問題の例を次に示します。

ユーザーAPIエンドポイント/サービスがサービスインターフェイスで指定されたもの以外の追加のプロパティ（パスワードなど）を返さないように指定したいと思います。 誤って余分なプロパティを持つオブジェクトを返した場合、結果のオブジェクトがオブジェクトリテラルによって生成されたかどうかに関係なく、コンパイル時エラーが発生します。

返されたすべてのオブジェクトの実行時チェックは、特に配列の場合、コストがかかる可能性があります。

この場合、過剰なプロパティチェックは役に立ちません。 正直なところ、私はそれが奇抜なワントリックポニーソリューションだと思います。 理論的には、「それだけで機能する」種類のエクスペリエンスを提供する必要がありました。実際には、混乱の原因にもなります。代わりに、正確なオブジェクトタイプを実装する必要があり、両方のユースケースを適切にカバーしていました。

@babaknessあなたのタイプNoExcessivePropsはノーオペレーションです。 私はそれらがこのような何かを意味すると思います：

interface API {
    username: () => { username: string }
}

const api: API = {
    username: (): { username: string } => {
        return { username: 'foobar', password: 'secret'} // error, ok
    }
}

const api2: API = {
    username: (): { username: string } => {
        const id: <X>(x: X) => X = x => x;
        const value = id({ username: 'foobar', password: 'secret' });
        return value  // no error, bad?
    }
}

APIタイプの作成者として、 usernameがユーザー名を返すだけであることを強制したいのですが、オブジェクトタイプには幅の制限がないため、どの実装者もそれを回避できます。 これは、リテラルの初期化時にのみ適用できます。これは、実装者が行う場合と行わない場合があります。 ただし、言語ベースのセキュリティとして正確な型を使用することを強くお勧めします。

@spion

この場合、過剰なプロパティチェックは役に立ちません。 正直なところ、私はそれが奇抜なワントリックポニーソリューションだと思います。 理論的には、彼らは「それはうまくいく」種類の経験を提供するべきでした

EPCは、かなり賢明で軽量な設計の選択肢であり、多くの問題をカバーします。 現実には、正確な型は「正しく機能する」わけではありません。 拡張性をサポートする健全な方法で実装するには、まったく異なる型システムが必要です。

@ jack-williamsもちろん、存在を確認する他の方法もあります（パフォーマンスが問題にならないランタイムチェック、テストなど）が、追加のコンパイル時の方法は、迅速なフィードバックのために非常に貴重です。

また、正確なタイプが「正しく機能する」という意味ではありませんでした。 私は、EPCが「正しく機能する」ことを意図していたことを意味しましたが、実際には、EPCは限られており、混乱し、安全ではありません。 主な理由は、「意図的に」使用しようとすると、通常、足を撃ってしまうからです。

編集：うん、混乱していることに気付いたので、「they」を「it」に置き換えるように編集しました。

@spion

また、正確なタイプが「正しく機能する」という意味ではありませんでした。 私は、EPCが「正しく機能する」ことを意図していたことを意味しましたが、実際には、EPCは限られており、混乱し、安全ではありません。 主な理由は、「意図的に」使用しようとすると、通常、足を撃ってしまうからです。

私の間違い。 元のコメントを次のように読む

理論的には、彼らは「それだけで機能する」種類のエクスペリエンスを提供する必要がありました[EPCではなく正確なタイプでした]

[]の解説は私の読書です。

改訂された声明：

理論的には、「それだけで機能する」ような体験を提供する必要がありました

はるかに明確です。 誤解してすみません！

type NoExcessiveProps<O> = {
  [K in keyof O]: K extends keyof O ? O[K] : never 
}

// no error
const getUser1 = (): {username: string} => {
  const foo = {username: 'foo', password: 'bar' }
  return foo 
} 

// Compile-time error, OK
const foo: NoExcessiveProps<{username: string}>  = {username: 'a', password: 'b' }

// No error? 🤔
const getUser2 = (): NoExcessiveProps<{username: string}> => {
  const foo = {username: 'foo', password: 'bar' }
  return foo 
}

以下のための結果getUser2 、それは一貫性のない感じ、それはコンパイル時エラーを生成しなければならないように、驚くべきことです。 なぜそうではないのかについての洞察は何ですか？

@babaknessあなたのNoExcessiveProps戻ったばかりに評価されT （同じキーを持つだけでなくタイプT ）。 中[K in keyof O]: K extends keyof O ? O[K] : never 、 Kいつもの鍵となるでしょうOあなたが上にマッピングされているので、 keyof O 。 const例では、 {username: string}入力した場合と同じように、EPCがトリガーされるためエラーが発生します。

追加の関数を呼び出してもかまわない場合は、渡されたオブジェクトの実際のタイプをキャプチャし、カスタム形式の過剰なプロパティチェックを実行できます。 （私は、全体のポイントがこのタイプのエラーを自動的にキャッチすることであることを理解しているので、これは限られた価値があるかもしれません）：

function checked<T extends E, E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
    return o;
}

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    return checked(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    return checked(foo) //ok
}

@dragomirtitianああ...そうです...良い点です！ だから私はあなたのchecked関数を理解しようとしています。 私は特に困惑しています

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    const bar = checked(foo) // error
    return checked(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    const bar = checked(foo) // error!?
    return checked(foo) //ok
}

getUser3のbar割り当ては失敗します。 エラーはfoo

エラーの詳細

ここでのbarのタイプは{}です。これは、 checkedにあるためと思われます。

function checked<T extends E, E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
    return o;
}

Eはどこにも割り当てられていません。 しかし、 typeof Eをtypeof {}に置き換えると、機能しません。

Eのタイプは何ですか？ ある種のコンテキストアウェアなことが起こっていますか？

@babakness型パラメーターを推測する場所が他にない場合、typescriptは戻り型から推測します。 我々は結果代入されているときにcheckedのリターンにgetUser* 、 E関数の戻り値の型になり、 Tなります返したい値の実際のタイプ。 Eを推測する場所がない場合は、デフォルトで{}設定されるため、常にエラーが発生します。

私がこのようにした理由は、明示的な型パラメーターを避けるためでした。より明示的なバージョンを作成できます。

function checked<E>() {
    return function <T extends E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
        return o;
    }
}

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    return checked<{ username: string }>()(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    return checked<{ username: string }>()(foo) //ok
}

注：部分的な引数の推論（https://github.com/Microsoft/TypeScript/pull/26349）がまだないため、カリー化された関数のアプローチが必要です。そのため、一部の型パラメーターを指定したり、他のパラメーターを推論したりすることはできません。同じ呼び出し。 これを回避するために、最初の呼び出しでEを指定し、2番目の呼び出しでTを推測します。 特定のタイプのcache関数をキャッシュして、キャッシュされたバージョンを使用することもできます

function checked<E>() {
    return function <T extends E>(o: T & Record<Exclude<keyof T, keyof E>, never>): E {
        return o;
    }
}
const checkUser = checked<{ username: string }>()

const getUser2 = (): { username: string } => {
    const foo = { username: 'foo', password: 'bar' }
    return checkUser(foo) //error
}
const getUser3 = (): { username: string } => {
    const foo = { username: 'foo' }
    return checkUser(foo) //ok
}

FWIWこれは、「公開された」メソッドから誤って余分なプロパティを返さないという特定の問題を解決するWIP /スケッチtslintルールです。

https://gist.github.com/spion/b89d1d2958f3d3142b2fe64fea5e4c32

スプレッドのユースケース（ https://github.com/Microsoft/TypeScript/issues/12936#issuecomment -300382189を参照）については、リンターがこのようなパターンを検出し、タイプセーフではないことを警告できますか？

前述のコメントからコード例をコピーします。

interface State {
   name: string;
}
function nameReducer(state: State, action: Action<string>): State {
   return {
       ...state,
       fullName: action.payload // compiles, but it's an programming mistake
   }
}

cc @JamesHenry / @ armano2

それが起こるのを見たいです。 GraphQLエンドポイント用に生成されたTypeScript定義を使用しますが、GraphQLは実行時にそのようなクエリを実行できないため、必要以上のフィールドを持つオブジェクトをクエリに渡してもTypeScriptでエラーが発生しないという問題があります。

3.5.1アップデートで、割り当て中に追加のプロパティをより適切にチェックすることで、これのどれだけが対処されていますか？ 3.5.1にアップグレードした後、エラーとしてフラグが立てられた既知の問題領域が多数ありました。

問題があり、正確なタイプが正しい解決策であると思われる場合は、元の問題をここに説明してください

https://github.com/microsoft/TypeScript/issues/12936#issuecomment -284590083

これがReact参照に関係するものです： https ：

/ cc @RyanCavanaugh

私のユースケースの1つは

export const mapValues =
  <T extends Exact<T>, V>(object: T, mapper: (value: T[keyof T], key: keyof T) => V) => {
    type TResult = Exact<{ [K in keyof T]: V }>;
    const result: Partial<TResult> = { };
    for (const [key, value] of Object.entries(object)) {
      result[key] = mapper(value, key);
    }
    return result as TResult;
  };

objectに追加のプロパティがある場合、それらの追加のキーと値でmapperを呼び出すのは安全ではないため、正確な型を使用しない場合、これは適切ではありません。

ここでの本当の動機は、コードで再利用できる列挙型の値をどこかに置きたいということです。

const choices = { choice0: true, choice1: true, choice2: true };
const callbacksForChoices = mapValues(choices, (_, choice) => () => this.props.callback(choice));

ここで、 this.props.callbackタイプは(keyof typeof choices) => voidです。

つまり、型システムは、型ランドのキーのセット（たとえば、和集合）と完全に一致するコードランドのキーのリストを持っているという事実を表現できるので、これを操作する関数を記述できます。キーのリストを作成し、結果について有効な型アサーションを作成します。 型システムが知る限り、コードランドオブジェクトは、使用されているオブジェクトタイプ以外の追加のプロパティを持つ可能性があるため、オブジェクト（前の例ではchoices ）を使用できません。 配列を使用することはできません（ ['choice0', 'choice1', 'choice2'] as const 。型システムが知る限り、配列には配列型で許可されているすべてのキーが含まれていない可能性があるためです。

たぶんexactは型であってはならず、関数の入力や出力の修飾子だけであるべきですか？ フローの分散修飾子のようなもの（ + / - ）

@phauxが今言ったことにExact実際に使用しているのは、コンパイラーに関数の形状を保証させることです。 フレームワークがある場合、 (T, S): AtMost<T> 、 (T, S): AtLeast<T> 、または(T, S): Exact<T>いずれかが必要になる場合があります。コンパイラーは、ユーザーが定義する関数が正確に適合することを確認できます。

いくつかの有用な例：
AtMostは設定に役立ちます（したがって、余分なparams / typosを無視せず、早期に失敗します）。
AtLeastは、reactコンポーネントやミドルウェアなど、ユーザーが必要なものをオブジェクトに追加する場合に最適です。
Exactは、シリアル化/逆シリアル化に役立ちます（データをドロップしないことを保証でき、これらは同形です）。

これは、これが発生するのを防ぐのに役立ちますか？

interface IDate {
  year: number;
  month: number;
  day: number;
}

type TBasicField = string | number | boolean | IDate;

 // how to make this generic stricter?
function doThingWithOnlyCorrectValues<T extends TBasicField>(basic: T): void {
  // ... do things with basic field of only the exactly correct structures
}

const notADate = {
  year: 2019,
  month: 8,
  day: 30,
  name: "James",
};

doThingWithOnlyCorrectValues(notADate); // <- this should not work! I want stricter type checking

TSでT extends exactly { something: boolean; } ? xxx : yyyと言う方法が本当に必要です。

または、次のようなものです。

const notExact = {
  something: true,
  name: "fred",
};

そこにxxxが返されます。

たぶんconstキーワードを使用できますか？ 例： T extends const { something: boolean }

@pleerockは、JavaScript / TypeScriptのように、変数をconstとして定義できますが、オブジェクトのプロパティを追加/削除できるため、少しあいまいな場合があります。 キーワードexactはかなりポイントだと思います。

正確に関連しているかどうかはわかりませんが、この場合、少なくとも2つのエラーが発生すると予想されます。
遊び場

@mityokそれは関係があると思います。 私はあなたが次の線に沿って何かをしたいと思っていると思います：

class Animal {
  makeSound(): exact Foo {
     return { a: 5 };
  }
}

もしexact型厳しいを作った-あなたがやったとして、それは、追加のプロパティを持つ拡張すべきではないDog 。

const （ as const ）を利用し、次のような前のインターフェイスとタイプを使用します。

const type WillAcceptThisOnly = number

function f(accept: WillAcceptThisOnly) {
}

f(1) // error
f(1 as WillAcceptThisOnly) // ok, explicit typecast

const n: WillAcceptThisOnly = 1
f(n) // ok

const変数に割り当てる必要があるのは本当に冗長ですが、期待したものと正確ではないtypealiasを渡すと、多くのエッジケースを回避できます。

私はExact<T>問題に対する純粋なTypeScriptソリューションを考え出しました。これは、メインの投稿で要求されたものとまったく同じように動作すると思います。

// (these two types MUST NOT be merged into a single declaration)
type ExactInner<T> = <D>() => (D extends T ? D : D);
type Exact<T> = ExactInner<T> & T;

function exact<T>(obj: Exact<T> | T): Exact<T> {
    return obj as Exact<T>;
};

ExactInner Exact含めてはならない理由は、＃32824修正がまだリリースされていないためです（ただし、 ！32924にすでにマージされてい

右辺の式もExact<T>である場合、タイプExact<T>の変数または関数の引数に値を割り当てることができます。ここで、 Tは両方の部分でまったく同じタイプです。割り当ての。

正確な型への値の自動昇格を実現していないので、それがexact()ヘルパー関数の目的です。 任意の値を正確な型に昇格させることができますが、TypeScriptが式の両方の部分の基になる型が拡張可能であるだけでなく、まったく同じであることを証明できる場合にのみ、割り当ては成功します。

TypeScriptがextend関係チェックを使用して、右側のタイプを左側のタイプに割り当てることができるかどうかを判断するという事実を利用して機能します。右側のタイプ（ソース）が左側のタイプ（宛先）を_拡張_する場合にのみ可能です。 。

checker.ts引用して、

// 2つの条件付きタイプ 'T1はU1を拡張しますか？ X1：Y1 'および' T2はU2を拡張しますか？ X2：Y2 'は次の場合に関連します
// T1とT2の一方が他方に関連し、U1とU2が同一のタイプであり、X1がX2に関連している、
//そしてY1はY2に関連しています。

ExactInner<T>ジェネリックは、説明されているアプローチを使用し、 U1とU2を、正確性チェックを必要とする基になるタイプに置き換えます。 Exact<T>は、プレーンな基になる型との共通部分を追加します。これにより、TypeScriptは、ターゲット変数または関数の引数が正確な型でない場合に、正確な型を緩和できます。

プログラマーの観点からは、 Exact<T>は、 Tを検査したり変更したりすることなく、また独立した型を作成することなく、 Tにexactフラグを設定するかのように動作します。

こちらが遊び場リンクと要点リンクです。

将来の改善の可能性は、非正確な型から正確な型への自動昇格を可能にし、 exact()関数の必要性を完全に排除することです。

素晴らしい作品@toriningen！

誰かがexactへの呼び出しであなたの価値を包む必要なしにこれを機能させる方法を見つけることができれば、それは完璧でしょう。

これが正しい問題かどうかはわかりませんが、これが私が働きたいことの例です。

https://www.typescriptlang.org/play/#code/KYOwrgtgBAyg9gJwC4BECWDgGMlriKAbwCgooBBAZyygF4oByAQ2oYBpSoVhq7GATHlgbEAvsWIAzMCBx4CTfvwDyCQQgBCATwAU -DNlz4AXFA

enum SortDirection {
  Asc = 'asc',
  Desc = 'desc'
}
function addOrderBy(direction: "ASC" | "DESC") {}
addOrderBy(SortDirection.Asc.toUpperCase());

@lookfirstそれは違います。 これは、 {foo: 1, bar: 2}が割り当てられないタイプexact {foo: number}ように、追加のプロパティを許可しないタイプの機能を求めています。 これは、存在しない可能性が高い列挙値に適用するテキスト変換を要求しているだけです。

これが正しい問題かどうかはわかりませんが、[...]

他の場所でのメンテナとしての私の経験では、疑わしくて明確な既存の問題を見つけることができなかった場合、新しいバグと最悪のシナリオを提出すると、見つけられなかった重複として閉じられます。 これは、ほとんどの主要なオープンソースJSプロジェクトに当てはまります。 （JSコミュニティの私たちの大規模なメンテナのほとんどは、実際にはまともな人々であり、バグレポートなどに本当に行き詰まる可能性がある人々であるため、時には本当に簡潔にならないようにするのは難しいです。）

@isiahmeadowsご回答ありがとうございます。 最初に重複する問題を検索していたため、新しい問題を提出しませんでした。これは正しいことです。 これが正しい問題であるかどうか、あるいは私が話していることをどのように分類するかさえわからなかったので、私は人々を困惑させないように努めていました。

別のサンプルユースケース：

https://www.typescriptlang.org/play/index.html#code/JYOwLgpgTgZghgYwgAgIoFdoE8AKcpwC2EkUAzsgN4BQydycAXMmWFKAOYDct9ARs1bsQ3agF9q1GOhAIwwAPYhkCKBDiQAKgAtgUACZ4oYXHA4QAqgCUAMgAoAjpiimChMswzYjREtDIAlFS8dGpg6FDKAAbaYGAADh4A9EkQAB5E8QA2EAB0CAqESQD8ACSUIBAA7sjWNgDK6lAI2j7udgDyfABWEHK5EODsEGSOzq5EgQFiUeKSKcgAolBQCuQANAwU6fF9kPrUqupaugZGJnjmdXaUDMwA5PebAsiPmwgPYLpkALTx + EQflVgFksj8EHB0GQID8vnp9H98CZEeZYQpwQQyNp7sgxAEeIclKxkP83BQALxUO6vJ7IF5vFSfb6ItxAkFgiFQmFwgws5H-VFgdGqOBYnFiAkLQC8G4BGPeQJl2Km0fQA1pxkPoIDBjhB9HSsFsyMAOCB1cAwPKFAwSQDiKRDmoNBAdPDzqYrrY7KTJvigA

編集：私はさらに速いと思うので、以下の@aigoncharovソリューションを確認してください。

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

これをもっと改善できるかどうかわからない。

type Exact<T, Shape> =
    // Check if `T` is matching `Shape`
    T extends Shape
        // Does match
        // Check if `T` has same keys as `Shape`
        ? Exclude<keyof T, keyof Shape> extends never
            // `T` has same keys as `Shape`
            ? T
            // `T` has more keys than `Shape`
            : never
        // Does not match at all
        : never;

type InexactType = {
    foo: string
}

const obj = {
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj)

コメントを省く

type ExactKeys<T1, T2> = Exclude<keyof T1, keyof T2> extends never
    ? T1
    : never

type Exact<T, Shape> = T extends Shape
    ? ExactKeys<T, Shape>
    : never;

これをもっと改善できるかどうかわからない。

type Exact<T, Shape> =
    // Check if `T` is matching `Shape`
    T extends Shape
        // Does match
        // Check if `T` has same keys as `Shape`
        ? Exclude<keyof T, keyof Shape> extends never
            // `T` has same keys as `Shape`
            ? T
            // `T` has more keys than `Shape`
            : never
        // Does not match at all
        : never;

type InexactType = {
    foo: string
}

const obj = {
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj)

コメントを省く

type ExactKeys<T1, T2> = Exclude<keyof T1, keyof T2> extends never
    ? T1
    : never

type Exact<T, Shape> = T extends Shape
    ? ExactKeys<T, Shape>
    : never;

そのアイデアが大好き！

仕事をすることができるもう一つのトリックは、両方向の割り当て可能性をチェックすることです。

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

type A = {
  prop1: string
}
type B = {
  prop1: string
  prop2: string
}
type C = {
  prop1: string
}

type ShouldBeNever = Exact<A, B>
type ShouldBeA = Exact<A, C>

http://www.typescriptlang.org/play/#code/C4TwDgpgBAogHgQwMbADwBUA0UBKA + KAXinSgjmAgDsATAZ1wCgooB + XMi6 + k5lt3vygAuKFQgA3CACc + o8VNmNQkKAEEiUAN58w0gPZgAjKLrBpASyoBzRgF9l4aACFNOlnsMmoZyzd0GYABMpuZWtg4q0ADCbgFeoX4RjI6qAMoAFvoArgA2NM4QAHKSMprwyGhq2M54qdCZOfmFGsQVKKjVUNF1QkA

@iamandrewlucaから別の遊び場https://www.typescriptlang.org/play/?ssl=7&ssc=6&pln=7&pc=17#code/C4TwDgpgBAogHgQwMbADwBUA0UBKA + KAXinSgjmAgDsATAZ1wCgooB + XMi6 + k5lt3vygAuKFQgA3CACc + o8VNmNQkKAElxiFOnDRiAbz4sAZgHtTousGkBLKgHNGAX0aMkpqlaimARgCsiKEMhMwsoAHJQ8MwjKB8EaVFw + Olw51djAFcqFBsPKEorAEYMPAAKYFF4ZDQsdU0anUg8AEoglyyc4DyqAogrACYK0Q1yRt02-RdlfuAist8-NoB6ZagAEnhIFBhpaVNZQuAhxZagA

ここでのニュアンスは、 Exact<{ prop1: 'a' }>をExact<{ prop1: string }>割り当てることができるかどうかです。 私のユースケースでは、そうすべきです。

@jeremybparagonあなたのケースはカバーされています。 ここにいくつかのケースがあります。

type InexactType = {
    foo: 'foo'
}

const obj = {
    // here foo is infered as `string`
    // and will error because `string` is not assignable to `"foo"`
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj) // $ExpectError

type InexactType = {
    foo: 'foo'
}

const obj = {
    // here we cast to `"foo"` type
    // and will not error
    foo: 'foo' as 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}
function test2(t: InexactType) {}

test1(obj) // $ExpectError
test2(obj)

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

このトリックを使用している人は誰でも（そしてそれの有効な使用法がないと言っているわけではありません）、「正確な」タイプでより多くの小道具を入手するのは非常に簡単であることを痛感する必要があります。 このようなものがある場合、 InexactTypeはExact<T, InexactType>割り当て可能であるため、次のことに気付かずに正確性から抜け出します。

function test1<T>(t: Exact<T, InexactType>) {}

function test2(t: InexactType) {
  test1(t); // inexactType assigned to exact type
}
test2(obj) // but 

遊び場リンク

これが、TSに正確な型がない理由です。これは、正確な型と非正確な型のオブジェクト型を完全にフォークする必要があり、たとえ不正確な型を正確な型に割り当てることができない場合でも同様です。額面価格でそれらは互換性があります。 不正確なタイプには、常により多くのプロパティが含まれる場合があります。 （少なくともこれが、 @ ahejlsbergがtsconfとして言及した理由の1つでした）。

asExactがそのような正確なオブジェクトをマークする構文上の方法である場合、このようなソリューションは次のようになります。

declare const exactMarker: unique symbol 
type IsExact = { [exactMarker]: undefined }
type Exact<T extends IsExact & R, R> =
  Exclude<keyof T, typeof exactMarker> extends keyof R? T : never;

type InexactType = {
    foo: string
}
function asExact<T>(o: T): T & IsExact { 
  return o as T & IsExact;
}

const obj = asExact({
  foo: 'foo',
});


function test1<T extends IsExact & InexactType>(t: Exact<T, InexactType>) {

}

function test2(t: InexactType) {
  test1(t); // error now
}
test2(obj) 
test1(obj);  // ok 

const obj2 = asExact({
  foo: 'foo',
  bar: ""
});
test1(obj2);

const objOpt = asExact < { foo: string, bar?: string }>({
  foo: 'foo',
  bar: ""
});
test1(objOpt);

遊び場リンク

@dragomirtitianだから、私は少し前に解決策を思いついたのですhttps://github.com/microsoft/TypeScript/issues/12936#issuecomment-524631270これに悩まされることはありません。

@dragomirtitian関数の入力方法の問題です。
少し違ったやり方でやれば、うまくいきます。

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

type InexactType = {
    foo: string
}

const obj = {
    foo: 'foo',
    bar: 'bar'
}

function test1<T>(t: Exact<T, InexactType>) {}

function test2<T extends InexactType>(t: T) {
  test1(t); // fails
}
test2(obj)

https://www.typescriptlang.org/play/#code/C4TwDgpgBAogHgQwMbADwBUA0UBKA + KAXinSgjmAgDsATAZ1wCgooB + XMi6 + k5lt3vygAuKFQgA3CACc + o8VNmNQkKAElxiFOnDRiAbz4sAZgHtTousGkBLKgHNGAX0aMkpqlaimARgCsiKEMhMwsoAHJQ8MwjKB8EaVFw + Olw51djAFcqFBsPKEorAEYMPAAKYFF4ZDQsdU0anUg8AEogl0YsnOA8qgKIKwAmDE5KWgYNckbdcsqSNuD + 4oqWgG4oAHoNqGMEGwAbOnTC4EGy3z82oA

@jeremybparagonあなたのケースはカバーされています。

@iamandrewlucaこことここの解決策は、私の例の扱い方が異なると思います。

type Exact<T, R> = T extends R
  ? R extends T
    ? T
    : never
  : never

type A = {
  prop1: 'a'
}
type C = {
  prop1: string
}

type ShouldBeA = Exact<A, C> // This evaluates to never.

const ob...

遊び場リンク

@aigoncharov問題は、これを簡単に行うことができず、 test1が追加のプロパティで呼び出される可能性があることを認識しておく必要があることです。 IMOは、型システムに正確さを強制することが重要であるため、偶発的な不正確な割り当てを簡単に許可できるソリューションはすでに失敗しています。

@toriningenええ、あなたの解決策はより良いようです、私は最後に投稿された解決策を参照していました。 あなたの解決策は、追加の関数型パラメーターを必要としないという事実に賛成ですが、オプションのプロパティではうまく機能しないようです：

// (these two types MUST NOT be merged into a single declaration)
type ExactInner<T> = <D>() => (D extends T ? D : D);
type Exact<T> = ExactInner<T> & T;
type Unexact<T> = T extends Exact<infer R> ? R : T;

function exact<T>(obj: Exact<T> | T): Exact<T> {
    return obj as Exact<T>;
};

////////////////////////////////
// Fixtures:
type Wide = { foo: string, bar?: string };
type Narrow = { foo: string };
type ExactWide = Exact<Wide>;
type ExactNarrow = Exact<Narrow>;

const ew: ExactWide = exact<Wide>({ foo: "", bar: ""});
const assign_en_ew: ExactNarrow = ew; // Ok ? 

遊び場リンク

@jeremybparagon @aigoncharovのソリューションが、オプションのプロパティでうまく機能するかどうかはわかりませんが。 T extends SとS extends T基づくソリューションは、次のような単純な事実に悩まされます。

type A = { prop1: string }
type C = { prop1: string,  prop2?: string }
type CextendsA = C extends A ? "Y" : "N" // Y 
type AextendsC = A extends C ? "Y" : "N" // also Y 

遊び場リンク

Exclude<keyof T, keyof Shape> extends neverを使用する@iamandrewlucaは良いと思います。私のタイプは非常に似ています（元の回答を編集して&Rを追加し、追加のチェックなしでT extends Rを確保しました）。

type Exact<T extends IsExact & R, R> =
  Exclude<keyof T, typeof exactMarker> extends keyof R? T : never;

私のソリューションには穴がないという評判を賭けるつもりはありませんが、私は彼らにとってそれほど難しいことは見ていませんが、そのような発見を歓迎します😊

これがグローバルに有効になっているフラグが必要です。 このように、タイプを緩めたい人は同じことを続けることができます。 この問題によって引き起こされるバグが多すぎます。 今、私はスプレッド演算子を避けてpickKeysFromObject(shipDataRequest, ['a', 'b','c'])を使用しようとしています

私が最近見つけた正確なタイプのユースケースは次のとおりです。

type PossibleKeys = 'x' | 'y' | 'z';
type ImmutableMap = Readonly<{ [K in PossibleKeys]?: string }>;

const getFriendlyNameForKey = (key: PossibleKeys) => {
    switch (key) {
        case 'x':
            return 'Ecks';
        case 'y':
            return 'Why';
        case 'z':
            return 'Zee';
    }
};

const myMap: ImmutableMap = { x: 'foo', y: 'bar' };

const renderMap = (map: ImmutableMap) =>
    Object.keys(map).map(key => {
        // Argument of type 'string' is not assignable to parameter of type 'PossibleKeys'
        const friendlyName = getFriendlyNameForKey(key);
        // No index signature with a parameter of type 'string' was found on type 'Readonly<{ x?: string | undefined; y?: string | undefined; z?: string | undefined; }>'.    
        return [friendlyName, map[key]];
    });
;

型はデフォルトで不正確であるため、 Object.keysはstring[]を返す必要があります（https://github.com/microsoft/TypeScript/pull/12253#issuecomment-263132208を参照）が、この場合、 ImmutableMapが正確である場合、 PossibleKeys[]返すことができなかった理由はありません。

@dallonfは、この例では正確な型だけでなく追加の機能が必要であることに注意してください。 Object.keysは単なる関数であり、正確な型に対してkeyof Tを返す関数を記述するためのメカニズムが必要です。他のタイプの場合はstring 。 正確な型を宣言するオプションがあるだけでは十分ではありません。

@RyanCavanaughそれは意味、正確なタイプ+それらを検出する能力だったと思います。

反応型のユースケース：

forwardRef<T, P>(render: (props: P, ref: Ref<T>) => ReactElement<P> & { displayName?: string }) => ComponentType<P> 。

通常のコンポーネントをforwardRefに渡したくなります。そのため、Reactはrender引数でpropTypesまたはdefaultPropsを検出すると、ランタイム警告を発行します。 これをタイプレベルで表現したいのですが、 neverにフォールバックする必要があります：

- forwardRef<T, P>(render: (props: P, ref: Ref<T>) => ReactElement<P> & { displayName?: string }) => ComponentType<P>
+ forwardRef<T, P>(render: (props: P, ref: Ref<T>) => ReactElement<P> & { displayName?: string, propTypes?: never, defaultProps?: never }) => ComponentType<P>

neverのエラーメッセージは役に立ちません（「{}は未定義に割り当てることができません」）。

誰かが@toriningenのソリューションがさまざまなイベントオブジェクトの形状の結合でどのように見えるかについて私を助けてくれますか？ redux-dispatch呼び出しでイベントの形を制限したいのですが、例：

type StoreEvent =
  | { type: 'STORE_LOADING' }
  | { type: 'STORE_LOADED'; data: unknown[] }

イベントの正確な形状のみを受け入れる型付きdispatch（）関数を作成する方法は不明です。

（更新：私はそれを理解しました：https：//gist.github.com/sarimarton/d5d539f8029c01ca1c357aba27139010）

使用事例：

Exact<>サポートがない場合、GraphQLミューテーションで実行時の問題が発生します。 GraphQLは、許可されたプロパティの正確なリストを受け入れます。 過剰な小道具を提供すると、エラーがスローされます。

したがって、フォームからデータを取得すると、Typescriptは過剰な（余分な）プロパティを検証できません。 また、実行時にエラーが発生します。

次の例は、架空の安全性を示しています

• 最初のケースでは、すべての入力パラメータを追跡しました
• しかし実際には（フォームからデータを取得して変数に保存する2番目のケースのように）Typescript

遊び場でお試しください

記事https://fettblog.eu/typescript-match-the-exact-object-shape/および上記で提供された同様のソリューションによると、次の醜いソリューションを使用できます。

このsavePerson<T>(person: ValidateShape<T, Person>)ソリューションが醜いのはなぜですか？

入力タイプが深くネストされていると仮定します。例：

// Assume we are in the ideal world where implemented Exact<>

type Person {
  name: string;
  address: Exact<Address>;
}

type Address {
   city: string
   location: Exact<Location>
}

type Location {
   lon: number;
   lat: number; 
}

savePerson(person: Exact<Person>)

現在利用可能なソリューションで同じ動作を実現するために、どのスパゲッティを作成する必要があるか想像できません。

savePerson<T, TT, TTT>(person: 
  ValidateShape<T, Person keyof ...🤯...
     ValidateShape<TT, Address keyof ...💩... 
         ValidateShape<TTT, Location keyof ...🤬... 
> > >)

したがって、今のところ、コードの静的分析には大きな穴があり、複雑なネストされた入力データを処理します。

最初の画像で説明した、「鮮度」が失われたためにTSが過剰なプロパティを検証しないケースも、私たちにとって少し悩みの種でした。

書き込み

doSomething({
  /* large object of options */
})

多くの場合、よりもはるかに読みにくいと感じます

const options = {
  /* large object of options */
}
doSomething(options)

const options: DoSomethingOptions = {明示的に注釈を付けることは役立ちますが、コードレビューで見つけて実施するのは少し面倒で難しいです。

これは少しオフトピックのアイデアであり、ここで説明する正確さのほとんどのユースケースを解決しませんが、囲んでいるスコープ内で1回だけ使用された場合、オブジェクトをリテラルに新鮮に保つことは可能でしょうか？

@RyanCavanaughEPCを説明してくれてありがとう... EPCと正確なタイプの違いはどこかでより詳細に議論されていますか？ 今、私は、EPCが正確な型では許可されないいくつかのケースを許可する理由をよりよく理解する必要があると感じています。

こんにちは@noppaそれは素晴らしいアイデアだと思います。 最初に変数に直接割り当てることと変数に割り当てることの違いに気付いたとき、私はこれに偶然出くわしました-私をここに連れてきたSOについての質問さえしました。 現在の動作は、少なくとも私にとっては驚くべきものです...

GraphQLミューテーションの例と同じ問題があると思います（正確なネストされた型付け、追加のプロパティは許可されるべきではありません）。 私の場合、共通のモジュール（フロントエンドとバックエンドで共有）にAPI応答を入力することを考えています。

export type ProductsSlashResponse = {
  products: Array<{
    id: number;
    description: string;
  }>,
  total: number;
};

サーバー側では、応答がその型署名を尊重していることを確認したいと思います。

router.get("products/", async () =>
  assertType<ProductsSlashResponse>(getProducts())));

私はここから解決策を試しました。 うまくいくように見えるのはT extends U ? U extends T ? T : never : neverで、カリー化された機能は理想的ではありません。 それに関する主な問題は、欠落しているプロパティや余分なプロパティに関するフィードバックが得られないことです（おそらくそれを改善することはできますが、ネストされたプロパティに入るとそれを行うのが難しくなります）。 他のソリューションは、深くネストされたオブジェクトでは機能しません。

もちろん、指定されたよりも多くの情報を送信してもフロントエンドは通常クラッシュしませんが、APIが必要以上の情報を送信すると、情報リークが発生する可能性があります（データベースからデータを読み取るという霧の性質のため）どのタイプが常にコードと同期しているとは限らない場合、これが発生する可能性があります）。

@ fer22f GraphQLは、クライアントが要求しなかったフィールドを送信しません... productsまたは配列要素にJSONスカラー型を使用している場合を除き、心配する必要はありません。

誤解して申し訳ありませんが、GraphQLを使用していると思いました

誰かがすでにGraphQLについて言及しましたが、「ユースケースの収集」（数年前のスレッドで@DanielRosenwasserが言及しました:-)「手元にユースケースがない」）という観点から、私が望んでいた2つのユースケースユースExactは次のとおりです。

1. データストア/データベース/ ORMへのデータの受け渡し-渡された余分なフィールドは、サイレントにドロップされるか、保存されません。

2. ワイヤーコール/ RPC / REST / GraphQLにデータを渡す-ここでも、渡される余分なフィールドはサイレントにドロップされるか、送信されません。

（まあ、静かに落とされないかもしれません、それらは実行時エラーである可能性があります。）

どちらの場合も、プログラマー/私自身に（コンパイルエラーを介して）伝えたいと思います。送信されました」、それはありません」。

これは、「部分更新」スタイルのAPI、つまりウィークタイプで特に必要です。

type Data = { firstName:? string; lastName?: string; children?: [{ ... }] };
const data = { firstName: "a", lastNmeTypo: "b" };
await saveDataToDbOrWireCall(data);

少なくとも1つのパラメータが一致するfirstNameの弱い型チェックに合格するため、100％互いに素ではありませんが、 lsatNmeTypo 「明らかな」タイプミスがまだあります。

確かに、EPCは次の場合に機能します。

await saveDataToDbOrWireCall({ firstName, lastNmeTypo });

しかし、すべてのフィールドを分解して再入力する必要があるのはかなり面倒です。

@jcalzのExactifyのようなソリューションは、第1レベルのプロパティで機能しますが、再帰的なケース（つまり、 childrenは配列であり、配列要素は正確である必要があります）ジェネリックスを使用した「実世界」のユースケース/ Exact<Foo<Bar<T>> 。

これが組み込まれていると便利であり、優先順位付け/ロードマッピングに役立つ場合は、これらの明示的なユースケース（基本的には部分的/弱いタイプのワイヤーコール）に注意したいと思います。

（FWIW https://github.com/stephenh/joist-ts/pull/35/filesには、現在、深いExactと、些細なケースを通過しているExact.test.tsでの試みがありますが、 PR自体には、より難解な使用法でコンパイルエラーがあります。免責事項この特定のPRを調べる人はいないと思いますが、「 Exactが役立つ場所」+「AFAICT」として提供しているだけです。これは、ユーザーランドのデータポイントでは実行が困難です。）

おい、

ここで正確なタイプのレコードとタプルの提案に関するTSチームの考えはどうですか？ https://github.com/tc39/proposal-record-tuple

それらの新しいプリミティブに正確な型を導入することは理にかなっていますか？

@slorber TSではありませんが、それは直交しています。 その提案は不変性に関するものであり、Immutable.jsのようなライブラリとの懸念はほぼ同じです。

@stephenh再帰バージョンで繰り返しました。 再帰を伴う未定義のケースを正しく処理するのに問題がありました。よりクリーンなソリューションを利用できます。 配列や複雑なデータ構造を持つ一部のエッジケースではおそらく機能しません。

export type Exact<Expected, Actual> = Expected &
  Actual & // Needed to infer `Actual`
  (null extends Actual
    ? null extends Expected
      ? Actual extends null // If only null stop here, because NonNullable<null> = never
        ? null
        : CheckUndefined<Expected, Actual>
      : never // Actual can be null but not Expected: forbid the field
    : CheckUndefined<Expected, Actual>);

type CheckUndefined<Expected, Actual> = undefined extends Actual
  ? undefined extends Expected
    ? Actual extends undefined // If only undefined stop here, because NonNullable<undefined> = never
      ? undefined
      : NonNullableExact<NonNullable<Expected>, NonNullable<Actual>>
    : never // Actual can be undefined but not Expected: forbid the field
  : NonNullableExact<NonNullable<Expected>, NonNullable<Actual>>;

type NonNullableExact<Expected, Actual> = {
  [K in keyof Actual]: K extends keyof Expected
    ? Actual[K] extends (infer ActualElement)[]
      ? Expected[K] extends (infer ExpectedElement)[] | undefined | null
        ? Exact<ExpectedElement, ActualElement>[]
        : never // Not both array
      : Exact<Expected[K], Actual[K]>
    : never; // Forbid extra properties
};

遊び場

正確なものは、API応答を返すときに非常に役立ちます。 現在、これは私たちが解決するものです：

const response = { companies };

res.json(exact<GetCompaniesResponse, typeof response>(response));

export function exact<S, T>(object: Exact<S, T>) {
  return object;
}

ここで、 Exactタイプは、 @ ArnaudBarreが上記で提供したもの

私のブロックを解除し、いくつかのtsを教えてくれた@ArnaudBarreに感謝します。
ソリューションのリフ：

export type Exact<Expected, Actual> =
  keyof Expected extends keyof Actual
    ? keyof Actual extends keyof Expected
      ? Expected extends ExactElements<Expected, Actual>
        ? Expected
        : never
      : never
    : never;

type ExactElements<Expected, Actual> = {
  [K in keyof Actual]: K extends keyof Expected
    ? Expected[K] extends Actual[K]
      ? Actual[K] extends Expected[K]
        ? Expected[K]
        : never
      : never
    : never
};

// should succeed (produce exactly the Expected type)
let s1: Exact< { a: number; b: string }, { a: number; b: string } >;
let s2: Exact< { a?: number; b: string }, { a?: number; b: string } >;
let s3: Exact< { a?: number[]; b: string }, { a?: number[]; b: string } >;
let s4: Exact< string, string >;
let s5: Exact< string[], string[] >;
let s6: Exact< { a?: number[]; b: string }[], { a?: number[]; b: string }[] >;

// should fail (produce never)
let f1: Exact< { a: string; b: string }, { a: number; b: string } >;
let f2: Exact< { a: number; b: string }, { a?: number; b: string } >;
let f3: Exact< { a?: number; b: string }, { a: number; b: string } >;
let f4: Exact< { a: number[]; b: string }, { a: string[]; b: string } >;
let f5: Exact< { a?: number[]; b: string }, { a: number[]; b: string } >;
let f6: Exact< { a?: number; b: string; c: string }, { a?: number; b: string } >;
let f7: Exact< { a?: number; b: string }, { a?: number; b: string; c: string } >;
let f8: Exact< { a?: number; b: string; c?: string }, { a?: number; b: string } >;
let f9: Exact< { a?: number; b: string }, { a?: number; b: string; c?: string } >;
let f10: Exact< never, string >;
let f11: Exact< string, never >;
let f12: Exact< string, number >;
let f13: Exact< string[], string >;
let f14: Exact< string, string[] >;
let f15: Exact< string[], number[] >;
let f16: Exact< { a?: number[]; b: string }[], { a?: number[]; b: string } >;

前のソリューションは、f6、f8、およびf9で「成功」しました。
このソリューションは、「よりクリーンな」結果も返します。 一致すると、「期待される」タイプが返されます。
@ArnaudBarreのコメントと

@heystewartあなたのExactは対称的な結果を与えません：

let a: Exact< { foo: number }[], { foo: number, bar?: string }[] >;
let b: Exact< { foo: number, bar?: string }[], { foo: number }[] >;

a = [{ foo: 123, bar: 'bar' }]; // error
b = [{ foo: 123, bar: 'bar' }]; // no error

編集： @ArnaudBarreのバージョンにも同じ問題があります

@papbはい、効果的に入力が機能しません。エントリポイントが配列です。 variablesが常にオブジェクトであるgraphQLAPIに必要でした。

これを解決するには、ExactObjectとExactArrayを分離し、どちらかに入るエントリポイントを用意する必要があります。

では、オブジェクトが正確なプロパティを持っていることを確認するための最良の方法は何でしょうか。

@ captain-yossarianは、TypeScriptチームにこれを実装するように説得します。 ここに示されている解決策は、予想されるすべてのケースで機能するわけではなく、ほとんどすべてが明確性に欠けています。

@toriningenは、TSチームがこの機能を実装する場合、いくつの問題がクローズされるかを想像できません。

@RyanCavanaugh
現在、私をここに連れてきたユースケースが1つあり、それはあなたのトピック「Miscellany」に直接当てはまります。 次のような関数が必要です。

1. オプションのパラメーターを持つインターフェースを実装するパラメーターを取ります
2. 指定されたパラメータのより狭い実際のインターフェイスに入力されたオブジェクトを返すため、

これらの当面の目標は、次の目的に役立ちます。

1. 入力の過剰なプロパティチェックを取得します
2. オートコンプリートとプロパティタイプを取得します-出力の安全性

例

私は自分のケースをこれに減らしました：

type X = {
    red?: number,
    green?: number,
    blue?: number,
}

function y<
    Y extends X
>(
    y: (X extends Y ? Y : X)
) {
    if ((y as any).purple) throw Error('bla')

    return y as Y
}

const z = y({
    blue: 1,
    red: 3,
    purple: 4, // error
})
z.green // error

type Z = typeof z

そのセットアップは機能し、すべての望ましい目標を達成するので、純粋な実現可能性の観点から、そしてこれに関する限り、私は良いです。 ただし、EPCは、パラメータに(X extends Y ? Y : X)入力することで実現されます。 私は基本的に偶然にそれを偶然見つけました、そして私はそれがうまくいったことに少し驚いた。

提案

そのため、ここの型に過剰なプロパティがないことを意図してマークするために、 extends代わりに使用できるimplementsキーワードが必要です。 そのようです：

type X = {
    red?: number,
    green?: number,
    blue?: number,
}

function x<
    Y implements X
>( y: Y ) {
    if ((y as any).purple) throw Error('bla')

    return y as Y
}

const z = y({
    blue: 1,
    red: 3,
    purple: 4, // error
})
z.green // error

type Z = typeof z

これは、現在の回避策よりもはるかに明確に思えます。 より簡潔であることに加えて、ジェネリックとパラメーターの間の現在の分割とは対照的に、ジェネリック宣言を使用して制約全体を特定します。

それはまた、現在不可能または非現実的であるが、現在は直感に過ぎないさらなるユースケースを可能にするかもしれません。

代替手段としての弱いタイプの検出

特に、＃3842による弱い型検出も同様に修正する必要があり、私のユースケースに従ってextendsに関連して機能する場合は、追加の構文を必要としないため、有利な場合があります。

Exact<Type>などについて

最後に、 implementsは、私が想像しているように、 Exact<Type>のより一般的なケースを解決しようとしないため、 function f<T extends Exact<{ n: number }>(p: T)についてのあなたのポイントに関してはかなり簡単なはずです。

一般に、 Exact<Type>は、EPCの次にはあまり役に立たないようであり、これらのグループに含まれない、一般的に有用な有効なケースを想像することはできません。

• 関数呼び出し：これらは私の例のように簡単に処理できるようになり、 implements恩恵を受けるでしょう
• 割り当て：リテラルを使用するだけなので、EPCが適用されます
• 制御ドメイン外からのデータ：タイプチェックではそれを防ぐことはできません。実行時に処理する必要があり、その時点で安全なキャストに戻ります。

明らかに、リテラルを割り当てることができない場合がありますが、これらも有限集合である必要があります。

• 関数で割り当てデータが与えられている場合は、呼び出しシグネチャで型チェックを処理します
• OPに従って複数のオブジェクトをマージする場合は、各ソースオブジェクトの型を適切にアサートすると、 as DesiredType安全にキャストできます。

要約： implementsはいいのですが、それ以外は問題ありません

要約すると、 implementsとEPCの修正（問題が発生した場合）により、正確なタイプを実際に処理する必要があると確信しています。

すべての利害関係者への質問：ここで実際に何か開いているものはありますか？

ここでユースケースを検討した結果、ほぼすべての再現が適切に処理され、残りは上記の私の小さな例で機能するようにできると思います。 それは疑問を投げかけます：最新のTSで今日これに関してまだ問題を抱えている人はいますか？

型注釈については未熟な考えがあります。 オブジェクトのマッチングはメンバーに分割され、正確に等しくなることも、それ以上でもそれ以下でも、多かれ少なかれ、多かれ少なかれ、多かれ少なかれでもあり得ます。 上記の各ケースで、1つの式が必要です。

完全に等しい、つまりそれ以上でもそれ以下でもない：

function foo(p:{|x:any,y:any|})

//it matched 
foo({x,y})
//no match
foo({x})
foo({y})
foo({x,y,z})
foo({})

より多く、しかしより少なくない：

function foo(p:{|x:any,y:any, ...|})

//it matched 
foo({x,y})
foo({x,y,z})

//no matched
foo({x})
foo({y})
foo({x,z})

それ以上でもそれ以下でも：

function foo(p:{x:any,y:any})

//it matched 
foo({x,y})
foo({x})
foo({y})

//no match
foo({x,z})
foo({x,y,z})

多かれ少なかれ：

function foo(p:{x:any,y:any, ...})

//it matched 
foo({x,y})
foo({x})
foo({y})
foo({x,z})
foo({x,y,z})

結論：

縦線がある場合は少なくないことを示し、縦線がない場合は少なくなる可能性があることを示します。 省略記号があるということは、それ以上ある可能性があることを意味し、省略記号がないということは、それ以上存在できないことを意味します。 配列の一致も同じ考えです。

function foo(p:[|x,y|]) // p.length === 2
function foo(p:[|x,y, ... |]) // p.length >= 2
function foo(p:[x,y]) // p.length >= 0
function foo(p:[x,y,...]) // p.length >= 0

あなたの例を使用して@rasenplanscher 、これはコンパイルします：

const x = { blue: 1, red: 3, purple: 4 };
const z = y(x);

ただし、正確なタイプでは、そうすべきではありません。 つまり、ここでの質問は、EPCに依存しないことです。

@ xp44mm 「多かれ少なかれ」はすでに動作であり、「多かれ少なかれ」はすべてのプロパティをオプションとしてマークした場合の動作です

function foo(p:{x?: any, y?: any}) {}
const x = 1, y = 1, z = 1
// all pass
foo({x,y})
foo({x})
foo({y})
const p1 = {x,z}
foo(p1)
const p2 = {x,y,z}
foo(p2)

同様に、正確な型がある場合、正確な型+オプションのすべてのプロパティは、基本的に「これ以上ではなく」になります。

この問題の別の例。 この提案の良いデモンストレーションだと思います。 この場合、私はrxjsを使用してSubjectを操作しますが、（「ロックされた」） Observable （ next 、 errorなどのメソッドを持たない）を返したいと考えています。価値。）

someMethod(): Observable<MyType> {
  const subject = new Subject<MyType>();

  // This works, but should not. (if this proposal is implemented.)
  return subject;

  // Only Observable should be allowed as return type.
  return subject.asObservable();
}

私は常に正確なタイプObservableのみを返し、それを拡張するSubjectは返したくありません。

提案：

// Adding exclamation mark `!` (or something else) to match exact type. (or some other position `method(): !Foo`, ...)
someMethod()!: Observable<MyType> {
  // ...
}

しかし、私はあなたがより良いアイデアを持っていると確信しています。 特にこれは戻り値に影響するだけではないからですよね？ とにかく、単なる擬似コードのデモ。 エラーや不足を回避するための優れた機能だと思います。 上記の場合のように。 別の解決策は、新しいユーティリティタイプを追加することです。
それとも私は何かを逃しましたか？ これはすでに機能しますか？ TypeScript4を使用しています。