少し遊んだだけで、現在、拡張タイプのオブジェクトを使用してこの拡張を実行できるため、これは正常に機能するはずです。

enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
const AdvEvents = {
    ...BasicEvents,
    Pause: "Pause",
    Resume: "Resume"
};

注意してください、あなたは近づくことができます

enum E {}

enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
function enumerate<T1 extends typeof E, T2 extends typeof E>(e1: T1, e2: T2) {
  enum Events {
    Restart = 'Restart'
  }
  return Events as typeof Events & T1 & T2;
}

const e = enumerate(BasicEvents, AdvEvents);

必要に応じて、別のオプションは共用体タイプを使用することです。

const enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
const enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
type Events = BasicEvents | AdvEvents;

let e: Events = AdvEvents.Pause;

欠点は、 Events.Pauseを使用できないことです。 AdvEvents.Pauseを使用する必要があります。 const列挙型を使用している場合、これはおそらく問題ありません。 そうしないと、ユースケースに十分でない可能性があります。

強く型付けされたReduxレデューサーにはこの機能が必要です。 TypeScriptに追加してください。

別の回避策は、列挙型を使用せずに、列挙型のように見えるものを使用することです。

const BasicEvents = {
  Start: 'Start' as 'Start',
  Finish: 'Finish' as 'Finish'
};
type BasicEvents = (typeof BasicEvents)[keyof typeof BasicEvents];

const AdvEvents = {
  ...BasicEvents,
  Pause: 'Pause' as 'Pause',
  Resume: 'Resume' as 'Resume'
};
type AdvEvents = (typeof AdvEvents)[keyof typeof AdvEvents];

すべての回避策は素晴らしいですが、可能な限り単純な徹底的なチェックを使用できるように、typescript自体からの列挙型継承のサポートを確認したいと思います。

列挙型の代わりにクラスを使用してください。

私はこれを試していました。

const BasicEvents = {
    Start: 'Start' as 'Start',
    Finish: 'Finish' as 'Finish'
};

type BasicEvents = (typeof BasicEvents)[keyof typeof BasicEvents];

const AdvEvents = {
    ...BasicEvents,
    Pause: 'Pause' as 'Pause',
    Resume: 'Resume' as 'Resume'
};

type AdvEvents = (typeof AdvEvents)[keyof typeof AdvEvents];

type sometype<T extends AdvEvents> =
    T extends typeof AdvEvents.Start ? 'Some String' :
    T extends typeof AdvEvents.Finish ? 'Some Other String' :
    T extends typeof AdvEvents.Pause ? 'Abc' :
    T extends typeof AdvEvents.Resume ? 'Xyz' : never;
type r = sometype<typeof AdvEvents.Finish>;

これを行うためのより良い方法がなければなりません。

なぜこれはすでに機能ではないのですか？ 重大な変更はなく、直感的な動作、この機能を積極的に検索して要求した80人以上の人々–それは簡単なことのようです。

名前空間内の別のファイルから列挙型を再エクスポートすることでさえ、列挙型を拡張せずに本当に奇妙です（そして、オブジェクトやタイプではなく、まだ列挙型である方法で列挙型を再エクスポートすることは不可能です）：

import { Foo as _Foo } from './Foo';

namespace Bar
{
    enum Foo extends _Foo {} // nope, doesn't work

    const Foo = _Foo;
    type Foo = _Foo;
}

Bar.Foo // actually not an enum

+1
現在回避策を使用していますが、これはネイティブの列挙型機能である必要があります。

私はこの問題をざっと見て、誰かが次の質問を提起したかどうかを確認しました。 （そうではないようです。）

OPから：

enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
enum AdvEvents extends BasicEvents {
    Pause = "Pause",
    Resume = "Resume"
};

AdvEventsがBasicEventsに割り当てられることを人々は期待しますか？ （たとえば、クラスの場合はextendsの場合です。）

はいの場合、列挙型は最終的なものであり、拡張できないという事実とどの程度一致していますか？

@masak素晴らしいポイント。 人々がここで望んでいる機能は、通常のextendsとはまったく異なります。 BasicEventsはAdvEventsに割り当てる必要があり、その逆ではありません。 通常のextends 、別の型をより具体的にするために改良します。この場合、他の型を拡張して値を追加するため、このためのカスタム構文では、おそらくextendsキーワードを使用しないでください。または、少なくとも構文enum A extends B {を使用しないでください。

その点で、私はOPからのこれの普及の提案が好きでした。

// extend enum using spread
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

拡散は、元のコピーが接続されていないコピーに浅く複製されるという期待をすでに持っているためです。

BasicEventsはAdvEventsに割り当てる必要があり、その逆ではありません。

それがすべての場合にどのように当てはまるかはわかりますが、私の言いたいことを理解すれば、すべての場合に当てはまるかどうかはわかりません。 ドメインに依存し、それらの列挙値がコピーされた理由に依存しているように感じます。

回避策についてもう少し考えました。https： //github.com/Microsoft/TypeScript/issues/17592#issuecomment -331491147を使用して、値にEventsを定義することで、もう少しうまくいくことができます。スペース：

enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
type Events = BasicEvents | AdvEvents;
const Events = {...BasicEvents, ...AdvEvents};

let e: Events = Events.Pause;

私のテストから、 Events.Startは型システムでBasicEvents.Startとして正しく解釈されているように見えるので、徹底的なチェックと識別された共用体の改良はうまく機能しているようです。 欠けている主な点は、 Events.Pauseを型リテラルとして使用できないことです。 AdvEvents.Pauseが必要です。 typeof Events.Pauseを使用すると、 AdvEvents.Pauseに解決されますが、私のチームの人々はそのようなパターンに混乱しているので、実際にはAdvEvents.Pauseを使用することをお勧めします。タイプとして。

（これは、孤立した列挙型ではなく、列挙型を相互に割り当て可能にしたい場合です。私の経験から、それらを割り当て可能にするのが最も一般的です。）

別の提案（元の問題は解決されませんが）、代わりに文字列リテラルを使用して型の共用体を作成するのはどうですか？

type BEs = "Start" | "Finish";

type AEs = BEs | "Pause" | "Resume";

let example: AEs = "Finish"; // there is even autocompletion

だから、私たちの問題の解決策はこれでしょうか？

const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
};
// { Start: string, Finish: string };


const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
} as const
// { Start: 'Start', Finish: 'Finish' };

https://github.com/Microsoft/TypeScript/pull/29510

列挙型の拡張は、TypeScriptのコア機能である必要があります。 言ってるだけ'

@wottpal以前の私の質問を繰り返します：

[列挙型を拡張できる]場合、列挙型は最終的なものであり、拡張できないという事実とどの程度一致していますか？

具体的には、列挙型の値に対するswitchステートメントの全体的なチェックは、列挙型の非拡張性に依存しているように思われます。

@masakなに？ いいえ、そうではありません！ 拡張列挙型はより広いタイプであり、元の列挙型に割り当てることができないため、使用するすべての列挙型のすべての値を常に知っています。 このコンテキストで拡張するということは、古い列挙型を変更するのではなく、新しい列挙型を作成することを意味します。

enum A { a; }
enum B extends A { b; }

declare var a: A;
switch(a) {
    case A.a:
        break;
    default:
        // a is never
}

declare var b: B;
switch(b) {
    case A.a:
        break;
    default:
        // b is B.b
}

@ m93aああ、つまり、ここでのextendsは、実際には（ AからB $への列挙値の）より多くの_copying_セマンティクスを持っているということですか？ そうすると、スイッチは正常に出てきます。

しかし、そこにはまだ私には壊れているように見える_いくつかの_期待があります。 それを突き止める方法として：クラスでは、 extendsはコピーセマンティクスを伝達しません—フィールドとメソッドは拡張サブクラスにコピーされません。 代わりに、プロトタイプチェーンを介して利用できるようになります。 スーパークラスには、フィールドまたはメソッドが1つだけあります。

このため、 class B extends Aの場合、 BがAに割り当て可能であることが保証されます。したがって、たとえばlet a: A = new B();は完全に問題ありません。

ただし、列挙型とextendsを使用すると、対応する保証がないため、 let a: A = B.b;を実行できません。 それが私にとって奇妙に感じることです。 ここでextendsは、何ができるかについての特定の一連の仮定を伝えますが、それらは列挙型では満たされていません。

次に、それをexpandsまたはclonesと呼びますか？ 🤷‍♂️
ユーザーの観点からは、基本的なことを簡単に実現できないのは奇妙に感じます。

合理的なセマンティクスがまったく新しいキーワードを必要とする場合（他の言語の先行技術はほとんどありません）、代わりにOPとこのコメントで提案されているスプレッド構文（ ... ）を再利用しませんか？

+1これがデフォルトの列挙機能に追加されることを願っています。 :)

誰かがエレガントな解決策を知っていますか？ 🧐

合理的なセマンティクスがまったく新しいキーワードを必要とする場合（他の言語の先行技術はほとんどありません）、代わりにOPとこのコメントで提案されているスプレッド構文（...）を再利用しませんか？

はい、もう少し考えてみると、この解決策は良いと思います。

この問題のスレッド全体を読んだ後、spread演算子を再利用することで問題が解決し、構文を混乱させる/直感的でないものにすることに関して人々が提起したすべての懸念に対処するという幅広い合意があるようです。

// extend enum using spread
enum AdvancedEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

この問題には、この時点で「Awaiting MoreFeedback」ラベル@RyanCavanaughが本当に必要ですか？

機能は+1を望んでいました

この問題に関するニュースはありますか？ 列挙型に拡散演算子を実装しておくと非常に便利です。

特に、列挙型をエイリアスおよび拡張する機能のメタプログラミングを含むユースケースでは、必須と必須の中間にあります。 上記の回避策のいずれかに頼らない限り、現在、1つの列挙型を別の名前でexport取得する方法はありません。

@ m93aああ、つまり、ここでのextendsは、実際には（ AからB $への列挙値の）より多くの_copying_セマンティクスを持っているということですか？ そうすると、スイッチは正常に出てきます。

しかし、そこにはまだ私には壊れているように見える_いくつかの_期待があります。 それを突き止める方法として：クラスでは、 extendsはコピーセマンティクスを伝達しません—フィールドとメソッドは拡張サブクラスにコピーされません。 代わりに、プロトタイプチェーンを介して利用できるようになります。 スーパークラスには、フィールドまたはメソッドが1つだけあります。

このため、 class B extends Aの場合、 BがAに割り当て可能であることが保証されます。したがって、たとえばlet a: A = new B();は完全に問題ありません。

ただし、列挙型とextendsを使用すると、対応する保証がないため、 let a: A = B.b;を実行できません。 それが私にとって奇妙に感じることです。 ここでextendsは、何ができるかについての特定の一連の仮定を伝えますが、それらは列挙型では満たされていません。

@masakあなたはほぼ正解だと思いますが、あなたは間違っている小さな仮定を1つしました。 enum B extends Aの場合、BはAに割り当て可能です。「割り当て可能」とは、Aが提供するすべての値がBで使用できることを意味します。 let a: A = B.bと言った場合、Bの値はAで使用可能です。これは、Aに割り当て可能な値とは異なります。BはAに割り当て可能であるため、 let a: A = B.aは正しいです。

これは、次の例のようなクラスを使用して明らかです。

class A {
 a() {}
}

class B extends A {
 b() {}
}

let a: A = new B();

a.a();  // valid
a.b();  // invalid via type system since `a` is typed as `A`

TypeScriptプレイグラウンドリンク

簡単に言えば、拡張は正しい用語であると私は信じています。それがまさに行われていることだからです。 enum B extends Aの例では、BはAの「サブクラス」（サブエナム？これにはもっと良い単語があるかもしれません）であるため、常にB列挙型にA列挙型のすべての可能な値が含まれることを期待できます。 Aに割り当て可能。

したがって、新しいキーワードは必要ないと思います。extendsを使用する必要があり、これはネイティブにTypeScriptの一部である必要があると思います：D

@julian-sf私はあなたが書いたすべてのものに同意すると思います...

...しかし...：slightly_smiling_face：

私がここで問題にしたように、この状況はどうですか？

// example from OP
enum BasicEvents {
    Start = "Start",
    Finish = "Finish"
};

// extend enum using "extends" keyword
enum AdvEvents extends BasicEvents {
    Pause = "Pause",
    Resume = "Resume"
};

PauseがAdvEventsの_インスタンス_であり、 AdvEvents _extends_ BasicEventsであるとすると、 PauseがBasicEventsの_インスタンス_であると期待しますか？

一方、列挙型（IMHO）のコアバリュープロポジションは、 switchステートメントのようなものが全体を想定できるように、列挙型が_closed _ / "final"（非拡張可能）であるということです。 （したがって、 AdvEventsがBasicEventであることの意味を_拡張_できることは、列挙型のある種の驚き最小の原則に違反します。）

次の3つのプロパティのうち2つを超えることはできないと思います。

• クローズされている列挙型/最終/予測可能な合計
• 2つのenum宣言間のextends関係
• bがBとB extends Aのインスタンスである場合、 bはAのインスタンスであるという（合理的な）仮定

@masak私は列挙型の閉じたプリンシパルを理解して同意します（実行時）。 ただし、コンパイル時の拡張は、すべてコンパイラによって定義および構築されるため、実行時にクローズド原則に違反することはありません。

bがBのインスタンスであり、BがAを拡張する場合、bはAのインスタンスであるという（合理的な）仮定

インスタンス/クラスの二分法は実際には列挙型に割り当てられないため、この推論は一種の誤解を招くと思います。 列挙型はクラスではなく、インスタンスもありません。 ただし、適切に実行すれば、拡張可能になると思います。 列挙型をセットのように考えてください。 この例では、BはAのスーパーセットです。したがって、Aの任意の値がBに存在すると想定するのが妥当ですが、Bの一部の値のみがAに存在します。

私は懸念がどこから来ているのか理解しています...しかし。 そして、私はそれについて何をすべきかわかりません。 列挙型拡張に関する問題の良い例：

const enum A { a = 'a' }
const enum B extends A { b = 'b' }

const foo = (a: A) => console.log(a);
const bar = (b: B) => foo(b);

bar(B.a); // 'a'
bar(B.b); // uh-oh, b doesn't exist on A, so foo would get unexpected behavior

// HOWEVER, this would work just fine...

const baz = (a: A) => bar(a);

baz(A.a); // 'a'
baz(B.a); // 'a'
baz(B.b); // compiler error as expected...

この場合、列挙型はクラスとはまったく異なる動作をします。 これらがクラスの場合、BをAに簡単にキャストできると期待できますが、ここでは明らかに機能しません。 私は必ずしもこれが悪いとは思いません、私はそれがただ説明されるべきだと思います。 IEでは、クラスのように継承ツリーで列挙型を上向きにスコープすることはできません。 これは、「Bのすべての値がAに存在するわけではないため、スーパーセット列挙型BをAに割り当てることができない」という行に沿ったコンパイラエラーで説明できます。

@ julian-sf

インスタンス/クラスの二分法は実際には列挙型に割り当てられないため、この推論は一種の誤解を招くと思います。 列挙型はクラスではなく、インスタンスもありません。

あなたは絶対に正しいです、それに直面して。

• 独立した言語構造として見られるように、列挙にはインスタンスではなく_members_があります。 「メンバー」という用語は、ハンドブックと言語仕様の両方で使用されています。 （C＃とPythonも同様に、「メンバー」という用語を使用します。「メンバー」はJavaでオーバーロードされた意味を持つため、Javaは「列挙型定数」を使用します。）
• コンパイルされたコードの観点から見ると、列挙型には_properties_があり、名前から値へ、および値から名前への両方の方法でマッピングされます。 繰り返しますが、インスタンスではありません。

これについて考えると、私はJavaの列挙型の考え方によって少し色付けされていることに気付きます。 Javaでは、列挙値は文字通り列挙型のインスタンスです。 実装に関しては、enumはEnumクラスを拡張するクラスです。 （手動で行うことは許可されていませんenumキーワードを使用する必要がありますが、これは内部で行われます。）これの良い点は、列挙型がすべての便利なクラスを取得することです。フィールド、コンストラクター、メソッドを持つことができます...このアプローチでは、列挙型メンバーはインスタンスです。 （JLSも同じように言っています。）

TypeScript列挙型セマンティクスへの変更を提案していないことに注意してください。 特に、TypeScriptを列挙型にJavaのモデルを使用するように変更する必要があると言っているのではありません。 私は、列挙型/列挙型メンバーの上にクラス/インスタンスの「理解」をオーバーレイすることは、有益で洞察に満ちていると言っています。 「列挙型はクラスである」または「列挙型メンバーはインスタンスである」ではありません...しかし、引き継がれる類似点があります。

どのような類似点がありますか？ 何よりもまず、メンバーシップを入力します。

enum Foo { A, B, C }
enum Bar { X, Y, Z }

let foo: Foo = Foo.C;
foo = Bar.Z;

Bar.ZはFooではないため、最後の行はタイプチェックしません。 繰り返しますが、これは_実際には_クラスとインスタンスではありませんが、 FooとBarがクラスであり、6つのメンバーがそれぞれのインスタンスであるかのように、同じモデルを使用して_理解_できます。

（この引数の目的上、 let foo: Foo = 2;も意味的に有効であり、一般にnumber値が列挙型の変数に割り当て可能であるという事実は無視します。）

列挙型には、_closed_という追加のプロパティがあります—申し訳ありませんが、これに適した用語はわかりません—一度定義すると、列挙型を拡張することはできません。 具体的には、列挙型宣言内にリストされているメンバーは、列挙型と型が一致する_only_ものです。 （「閉世界仮説」のように「閉」。）これは、列挙型のswitchステートメントのすべてのケースがカバーされていることを完全に確実に確認できるため、優れたプロパティです。

列挙型にextendsがある場合、このプロパティはウィンドウの外に出ます。

あなたが書く、

私は列挙型の閉じたプリンシパルを理解し、同意します（実行時）。 ただし、コンパイル時の拡張は、すべてコンパイラによって定義および構築されるため、実行時にクローズド原則に違反することはありません。

列挙型を拡張するコードがプロジェクトに含まれていることを前提としているため、これは真実ではないと思います。 ただし、サードパーティのモジュールで列挙型を拡張できます。突然、コンパイルするコードの制御外で、列挙型にも割り当て可能な_new_enumメンバーが存在します。 基本的に、列挙型は、コンパイル時でさえも閉じられなくなります。

私はまだ私が意味することを正確に表現するのに少し不器用だと感じていますが、それは重要だと思います：$＃$ enum ＃$のextendsは列挙型の最も貴重な機能の1つを壊します再閉鎖。 まさにこの理由から、列挙型を絶対的に_禁止_拡張/サブクラス化する言語の数を数えてください。

回避策についてもう少し考えました。 ＃17592（コメント）を使用して、値スペースにEventsを定義することで、もう少しうまくいくことができます。

enum BasicEvents {
  Start = 'Start',
  Finish = 'Finish'
}
enum AdvEvents {
  Pause = 'Pause',
  Resume = 'Resume'
}
type Events = BasicEvents | AdvEvents;
const Events = {...BasicEvents, ...AdvEvents};

let e: Events = Events.Pause;

私のテストから、 Events.Startは型システムでBasicEvents.Startとして正しく解釈されているように見えるので、徹底的なチェックと識別された共用体の改良はうまく機能しているようです。 欠けている主な点は、 Events.Pauseを型リテラルとして使用できないことです。 AdvEvents.Pauseが必要です。 あなたはtypeof Events.Pauseを使用でき、 AdvEvents.Pauseに解決されますが、私のチームの人々はそのようなパターンに混乱しているので、実際にはAdvEvents.Pauseを使用することをお勧めします。タイプとして。

（これは、孤立した列挙型ではなく、列挙型を相互に割り当て可能にしたい場合です。私の経験から、それらを割り当て可能にするのが最も一般的です。）

これが今のところ最も近い解決策だと思います。

ありがとう@alangpierce ：+1：

これに関する更新はありますか？

@sdwvit私は中核的な人物ではありませんが、私の見地からすると、次の構文提案（OPからですが、その後2回再提案されます）は、既知の問題なしに、すべての人を幸せにします。

// extend enum using spread
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause",
    Resume = "Resume"
};

extendsを使用せずに、この一見便利な「この他の列挙型のすべてのメンバーを複製する」機能を実装することを意味するため、_me_は幸せになります。これは、私が述べた理由で問題があると考えています。 ...構文は、拡張ではなくコピーすることでこれらの問題を回避します。

この問題はまだ「フィードバックを待っています」とマークされており、コアメンバーが必要だと感じる限り、そのカテゴリにとどまる権利を尊重します。 しかしまた、誰かが上記を実装してPRとして提出することを妨げるものは何もありません。

@masakご回答ありがとうございます。 私は今、すべての議論の歴史を経験しなければなりません。 後に戻ってきます:)

私はこれが起こるのを絶対に見たいと思いますし、これを自分で実装しようと絶対に望んでいます。 ただし、すべての列挙型の動作を定義する必要があります。 これはすべて文字列ベースの列挙型でうまく機能しますが、バニラ数値列挙型についてはどうでしょうか。 ここで拡張/コピーはどのように機能しますか？

• 「同じタイプ」の列挙型（数値は数値を拡張し、文字列は文字列を拡張します）で列挙型を拡張することだけを許可したいと思います。 異種列挙型は技術的にサポートされているので、そのサポートを維持する必要があると思います。

• 複数の列挙型からの拡張を許可する必要がありますか？ それらはすべて相互に排他的な値を持つ必要がありますか？ または、値の重複を許可しますか？ 辞書式順序に基づく優先順位？

• 拡張列挙型は拡張列挙型の値をオーバーライドできますか？

• 拡張列挙型は、値のリストの先頭として表示される必要がありますか、それとも任意の順序にすることができますか？ 後で定義された値の方が優先度が高いと思いますか？

• 暗黙の数値は、拡張された数値列挙型の最大値の後に1つ続くと思います。

• ビットマスクに関する特別な考慮事項？

などなど。

@JeffreyMercadoこれらは良い質問であり、実装を試みたい人に適しています。 ：笑顔：

以下は、「保守的な」設計アプローチに基づいた私の回答です（「下位互換性を維持しながら、後で変更するのが難しい選択を行うのではなく、不明なケースを許可しない設計上の決定を下しましょう」など）。

• 「同じタイプ」の列挙型で列挙型を拡張することだけを許可したいと思います（数値は数値を拡張し、文字列は文字列を拡張します）

私もそう思います。 結果として得られる混合型の列挙型は、あまり有用ではないようです。

• 複数の列挙型からの拡張を許可する必要がありますか？ それらはすべて相互に排他的な値を持つ必要がありますか？ または、値の重複を許可しますか？ 辞書式順序に基づく優先順位？

これは、私たちが話しているセマンティクスをコピーしているため、複数の列挙型を複製することは、C++の多重継承よりも「大丈夫」のようです。 特にオブジェクトスプレッドのアナロジーに基づいて構築し続ける場合、問題はすぐにはわかりません： let newEnum = { ...enumA, ...enumB };

すべてのメンバーが相互に排他的な値を持つ必要がありますか？ 保守的なことは、「はい」と言うことです。 繰り返しになりますが、オブジェクトスプレッドのアナロジーは、代替のセマンティクスを提供します。最後の1つが勝ちます。

列挙値をオーバーライドできれば幸いなユースケースは考えられません。 しかし、それは私の側の想像力の欠如かもしれません。 衝突を禁止する保守的なアプローチには、説明/内部化が容易な心地よい特性があり、少なくとも理論的には、実際の設計エラー（新しいコード、または維持されているコード）が明らかになる可能性があります。

• 拡張列挙型は拡張列挙型の値をオーバーライドできますか？

この場合の答えと理由は、前の場合とほとんど同じだと思います。

• 拡張列挙型は、値のリストの先頭として表示される必要がありますか、それとも任意の順序にすることができますか？ 後で定義された値の方が優先度が高いと思いますか？

これは、オーバーライドの「最後の1つが勝つ」セマンティクスを使用する場合にのみ重要であると最初に言いました。

しかし、考え直してみると、「衝突なし」と「最後の1つが勝つ」の両方で、列挙型がリストに広がる前に列挙型メンバー宣言を配置するのは奇妙だと思います。 たとえば、そうすることでどのような意図が伝えられているのでしょうか。 スプレッドは「輸入品」に少し似ており、従来はこれらが一番​​上にあります。

列挙型メンバーの宣言の後に列挙型スプレッドを配置することを必ずしも禁止したくはありません（ただし、文法で許可されていなくても問題ないと思います）。 それが許可されることになった場合、それは間違いなく、リンターとコミュニティの慣習が回避可能であると指摘することができるものです。 そうする理由はありません。

• 暗黙の数値は、拡張された数値列挙型の最大値の後に1つ続くと思います。

おそらく保守的なことは、スプレッド後の最初のメンバーに明示的な値を要求することです。

• ビットマスクに関する特別な考慮事項？

それは上記のルールでカバーされると思います。

列挙型、インターフェイス、および不変オブジェクトを組み合わせることで、合理的なことを行うことができました。

export enum Unit {
    SECONDS,
    MINUTES,
    HOURS,
    DAYS,
    WEEKS,
    MONTHS,
    YEARS,
    DECADES,
    CENTURIES,
    MILLENNIA
}

interface Labels {
    SINGULAR: Record<Unit, string>
    PLURAL: Record<Unit, string>
    LAST: string;
    DELIM: string;
    NOW: string;
}

export const EnglishLabels: Labels = {
    SINGULAR: {
        [Unit.SECONDS]: ' second',
        [Unit.MINUTES]: ' minute',
        [Unit.HOURS]: ' hour',
        [Unit.DAYS]: ' day',
        [Unit.WEEKS]: ' week',
        [Unit.MONTHS]: ' month',
        [Unit.YEARS]: ' year',
        [Unit.DECADES]: ' decade',
        [Unit.CENTURIES]: ' century',
        [Unit.MILLENNIA]: ' millennium'
    },
    PLURAL: {
        [Unit.SECONDS]: ' seconds',
        [Unit.MINUTES]: ' minutes',
        [Unit.HOURS]: ' hours',
        [Unit.DAYS]: ' days',
        [Unit.WEEKS]: ' weeks',
        [Unit.MONTHS]: ' months',
        [Unit.YEARS]: ' years',
        [Unit.DECADES]: ' decades',
        [Unit.CENTURIES]: ' centuries',
        [Unit.MILLENNIA]: ' millennia'
    },
    LAST: ' and ',
    DELIM: ', ',
    NOW: ''
}

@illeatmyhatこれは列挙型の良い使い方ですが...既存の列挙型を拡張するものとしてどのようにカウントされるのかわかりません。 あなたがしているのは列挙型を_使用_することです。

（また、列挙型やswitchステートメントとは異なり、あなたの例では完全性チェックがないようです。後で列挙型メンバーを追加した人は、 SINGULARとPLURALに対応するキーを追加するのを簡単に忘れてしまう可能性があります。 LabelのすべてのインスタンスでPLURALレコード。）

@masak

後で列挙型メンバーを追加した人は、 Label SINGULARおよびPLURALレコードに対応するキーを追加するのを簡単に忘れてしまう可能性があります。）

少なくとも私の環境では、列挙型メンバーがSINGULARまたはPLURALのいずれかにない場合、エラーがスローされます。 Recordタイプがその役割を果たしていると思います。

TSのドキュメントは優れていますが、多くの機能を簡単な方法で組み合わせる方法の例は多くないと思います。 enum inheritanceは、国際化の問題を解決しようとしたときに最初に調べたもので、このスレッドにつながりました。 とにかくアプローチが間違っていることが判明したので、私はこの投稿を書きました。

@illeatmyhat

少なくとも私の環境では、列挙型メンバーがSINGULARまたはPLURALのいずれかにない場合、エラーがスローされます。 Recordタイプがその役割を果たしていると思います。

おー！ TIL。 そして、はい、それはそれをはるかに面白くします。 最初に列挙型の継承に到達し、最終的にパターンに到達することについて、あなたが何を意味しているのかわかります。 それは孤立したことではないかもしれません。 「X/Yの問題」は本物です。 「 MyEnumを拡張したい」という考えから始めても、最終的にRecord<MyEnum, string>を使用する人が増える可能性があります。

@masakに返信：

列挙型のextendsを使用すると、このプロパティはウィンドウの外に出ます。

あなたが書く、

@ julian-sf：列挙型のクローズドプリンシパルを理解し、同意します（実行時）。 ただし、コンパイル時の拡張は、すべてコンパイラによって定義および構築されるため、実行時にクローズド原則に違反することはありません。

列挙型を拡張するコードがプロジェクトに含まれていることを前提としているため、これは真実ではないと思います。 ただし、サードパーティのモジュールで列挙型を拡張できます。突然、コンパイルするコードの制御外で、列挙型にも割り当て可能な新しい列挙型メンバーができます。 基本的に、列挙型は、コンパイル時でさえも閉じられなくなります。

これについて考えれば考えるほど、あなたは完全に正しいです。 列挙型を閉じる必要があります。 列挙型を「作成する」というアイデアが本当に好きです。これが私たちがここで望んでいる問題の核心だと思うからです🥳。

この表記は、2つの別々の列挙型を「つなぎ合わせる」という概念を非常にエレガントに要約していると思います。

enum ComposedEnum = { ...EnumA, ...EnumB }

したがって、 extendsという用語の使用を辞任したことを考慮してください😆

@JeffreyMercadoの質問に対する@masakの回答へのコメント：

• 「同じタイプ」の列挙型（数値は数値を拡張し、文字列は文字列を拡張します）で列挙型を拡張することだけを許可したいと思います。 異種列挙型は技術的にサポートされているので、そのサポートを維持する必要があると思います。

私もそう思います。 結果として得られる混合型の列挙型は、あまり有用ではないようです。

私はそれが役に立たないことに同意しますが、おそらくここで列挙型の異種サポートを維持する必要があります。 ここではリンター警告が役立つと思いますが、TSがその邪魔になることはないと思います。 不自然なユースケースを考えることができます。つまり、数値と文字列が混在するフラグを取得する、非常に不十分に設計されたAPIとの対話用の列挙型を構築しています。 考案された、私は知っていますが、それは他の場所で許可されているので、ここでそれを禁止するべきではないと思います。

たぶん、そうしないように強く励ましますか？

• 複数の列挙型からの拡張を許可する必要がありますか？ それらはすべて相互に排他的な値を持つ必要がありますか？ または、値の重複を許可しますか？ 辞書式順序に基づく優先順位？

これは、私たちが話しているセマンティクスをコピーしているため、複数の列挙型を複製することは、C++の多重継承よりも「大丈夫」のようです。 特にオブジェクトスプレッドのアナロジーに基づいて構築し続ける場合は、すぐには問題が発生しません。let newEnum = {... enumA、... enumB};

100％同意する

• すべてのメンバーが相互に排他的な値を持つ必要がありますか？

保守的なことは、「はい」と言うことです。 繰り返しになりますが、オブジェクトスプレッドのアナロジーは、代替のセマンティクスを提供します。最後の1つが勝ちます。

私はここで引き裂かれています。 価値観の相互独占を強制することが「ベストプラクティス」であることに同意しますが、それは正しいですか？ これは、一般的に知られているスプレッドセマンティクスとは正反対です。 一方では、相互に排他的な値を適用するというアイデアが好きですが、他方では、スプレッドセマンティクスがどのように機能するかについての多くの仮定を破ります。 「最後の1つが勝つ」という通常の拡散ルールに従うことの欠点はありますか？ 実装が簡単なようです（基になるオブジェクトはとにかく単なるマップであるため）。 しかし、それはまた、一般的な期待と一致しているようです。 私はそれほど驚くことではないことに傾いています。

値をオーバーライドしたい場合の良い例もあるかもしれません（私はそれらが何であるかはわかりませんが）。

しかし、考え直してみると、「衝突なし」と「最後の1つが勝つ」の両方で、列挙型がリストに広がる前に列挙型メンバー宣言を入れたいと思うのは奇妙だと思います。 たとえば、そうすることでどのような意図が伝えられているのでしょうか。 スプレッドは「輸入品」に少し似ており、従来はこれらが一番​​上にあります。

それは、スプレッドのセマンティクスに従っている場合は、順序が何であるかは問題ではないかどうかによって異なります。 正直なところ、相互に排他的な値を適用している場合でも、順序は実際には重要ではありませんよね？ 衝突は、順序に関係なく、その時点でエラーになります。

• 暗黙の数値は、拡張された数値列挙型の最大値の後に1つ続くと思います。

おそらく保守的なことは、スプレッド後の最初のメンバーに明示的な値を要求することです。

同意します。 列挙型を拡散する場合、TSは追加のメンバーに明示的な値を適用する必要があります。

@ julian-sf

したがって、この用語の使用に関する私の辞任は延長されると考えてください😆

：+1：合計タイプ保存協会は傍観者から歓声を上げています。

しかし、考え直してみると、「衝突なし」と「最後の1つが勝つ」の両方で、列挙型がリストに広がる前に列挙型メンバー宣言を入れたいと思うのは奇妙だと思います。 たとえば、そうすることでどのような意図が伝えられているのでしょうか。 スプレッドは「輸入品」に少し似ており、従来はこれらが一番​​上にあります。

それは、スプレッドのセマンティクスに従っている場合は、順序が何であるかは問題ではないかどうかによって異なります。 正直なところ、相互に排他的な値を適用している場合でも、順序は実際には重要ではありませんよね？ 衝突は、順序に関係なく、その時点でエラーになります。

私は「通常のメンバー宣言の後にスプレッドを配置する正当な理由はない」と言っています。 「適切な制限の下で、それらを前後に配置しても違いはありません」と言っています。 これらの両方が同時に真実である可能性があります。

結果の主な違いは、通常のメンバーの前にスプレッドを許可または禁止する範囲にあるようです。 構文的に禁止されている可能性があります。 リンター警告が発生する可能性があります。 または、すべての点で完全に問題ない可能性があります。 順序に意味的な違いがない場合は、列挙型スプレッド機能を驚き最小の原則に準拠させ、使いやすく、教えたり説明したりするのが簡単になります。

Spread演算子を使用すると、JSおよびTypeScript全体で浅いコピーが広く使用されることになります。 確かに、 extendsを使用するよりも広く使用され、理解しやすい方法です。これは、直接的な関係を意味します。 コンポジションを介して列挙型を作成する方が、より簡単に使用できるソリューションになります。

提案の回避策のいくつかは、有効で使用可能ですが、同じ望ましい結果を達成するために、より多くの定型コードを追加します。 列挙型の最終的で不変の性質を考えると、他の言語と一貫性のあるプロパティを維持するために、合成によって追加の列挙型を作成することが望ましいでしょう。

この会話で3年がまだ続いているのは残念です。

@ jmitchell38488コメントにいいねを付けたいのですが、最後の文で気が変わりました。 提案されたソリューションが機能するため、これは必要な議論ですが、クラスとインターフェイスをこのように拡張する可能性も意味します。 これは大きな変更であり、c ++のような言語のプログラマーがtypescriptを使用するのを怖がらせる可能性があります。これは、基本的に同じことを行う2つの方法（ class A extends Bとclass A { ...(class B {}) } ）で終わるためです。 どちらの方法もサポートできると思いますが、一貫性を保つために列挙型にもextendが必要です。

@masak wdyt？ ^

@sdwvit私は、クラスとインターフェイスを作成するための動作を変更することについては考えていません。具体的には、列挙型について話し、合成を通じてそれらを作成しています。 これらは不変の最終型であるため、通常の継承方法で拡張することはできません。

JSの性質と最終的なトランスパイルされた値を考えると、構成を達成できない理由はありません。 確かに、列挙型での作業はより魅力的になります。

@masak wdyt？ ^

うーん。 言語の一貫性は称賛に値する目標だと思います。したがって、クラスとインターフェースで同様の...機能を要求することは_先験的に_間違っていません。 しかし、ケースは弱いか存在しないと思います。2つの理由があります。（a）クラスとインターフェイスにはすでに拡張メカニズムがあり、2つ目のものを追加しても、付加価値はほとんどありません（列挙型に提供すると、人々のユースケースがカバーされます）何年もの間、この問題に戻ってきました）; （b）クラスはある意味でEcmaScript仕様からのものであるため、クラスに新しい構文とセマンティクスを追加すると、承認の基準がはるかに高くなります。 （TypeScriptはES6よりも古いですが、前者を後者に近づけるための積極的な取り組みが行われています。これには、追加機能を追加しないことも含まれます。）

このスレッドは、実際のユースケースをカバーする価値のある機能であるという理由だけで長い間開かれていると思いますが、PRはまだ作成されていません。 このようなPRを作成するには、機能が必要だと言うだけでなく、時間と労力がかかります。 ：ウィンク：

この機能に取り組んでいる人はいますか？

この機能に取り組んでいる人はいますか？

私の推測では、私たちはそれについての議論さえ終わっていないので、ハハ！

これがどのようになるかについてのコンセンサスに近づいたように感じます。 これは言語の追加になるため、この提案を進めるにはおそらく「チャンピオン」が必要になります。 TSチームの誰かが来て、問題を「フィードバック待ち」から「提案待ち」（または同様のもの）に移す必要があると思います。

私はそれのプロトタイプに取り組んでいます。 時間の不足とコードの構造に不慣れなため、私はそれほど遠くまでは行きませんでしたが。 私はこれを見抜いたいと思っています。他に動きがなければ、できる限り続けます。

この機能も気に入っていただければ幸いです。 37ヶ月が経過しました、うまくいけばすぐに進歩が見られます

最近の会議からのメモ：

• extendsはサブタイプを意味するのに対し、列挙型を「拡張」するとスーパータイプが作成されるため、スプレッド構文が気に入っています。

  enum BasicEvents {
   Start = "Start",
   Finish = "Finish"
  }
  enum AdvEvents {
   ...BasicEvents,
   Pause = "Pause",
   Resume = "Resume"
  }
  

• AdvEvents.StartはBasicEvents.Startと同じタイプIDに解決されると考えられています。 これは、タイプBasicEvents.StartとAdvEvents.Startが相互に割り当て可能であり、タイプBasicEventsがAdvEventsに割り当て可能であることを意味します。 これが直感的に理解できることを願っていますが、これは、スプレッドが単なる構文上のショートカットではないことを意味することに注意することが重要です。スプレッドをその意味のように拡張すると、次のようになります。

  enum BasicEvents {
   Start = "Start",
   Finish = "Finish"
  }
  enum AdvEvents {
   Start = "Start",
   Finish = "Finish",
   Pause = "Pause",
   Resume = "Resume"
  }
  

  これには異なる動作があります。ここでは、文字列列挙型の品質が不透明であるため、 BasicEvents.StartとAdvEvents.Startを相互に割り当てることはできません。

  この実装のもう1つの小さな結果は、 AdvEvents.Startがクイック情報でBasicEvents.Startとしてシリアル化され、宣言が発行されることです（少なくとも、メンバーをAdvEventsにリンクする構文コンテキストがない場合） —リテラル式AdvEvents.Startにカーソルを合わせると、 AdvEvents.Startというクイック情報が表示される可能性がありますが、それでもBasicEvents.Startを表示する方が明確な場合があります）。

• これは、文字列列挙型でのみ許可されます。

これを試してみたいです。

明確にするために：これは実装が承認されていません。

ここには2つの可能な動作があり、どちらも悪いように見えます。

オプション1：それは実際には砂糖です

Spreadが実際にSpreadedenumのメンバーをコピーすることと同じ意味である場合、拡張enumの値を拡張enumの値であるかのように使用しようとしても、機能しない場合は大きな驚きがあります。

オプション2：実際には砂糖ではない

推奨されるオプションは、スプレッドがスレッドの上部近くにある@aj-rの共用体タイプの提案のように機能することです。 それが人々がすでに望んでいる振る舞いである場合、理解しやすいように、テーブル上の既存のオプションが厳密に望ましいように思われます。 それ以外の場合は、他の文字列列挙型のように動作しない新しい種類の文字列列挙型を作成しています。これは奇妙で、ここでの提案の「単純さ」を損なうようです。

人々はどのような行動を望んでいますか、そしてその理由は何ですか？

オプション1は大きな驚きにつながるので、私はそれを望んでいません。

オプション2が必要ですが、@ aj-rの欠点を克服するのに十分な構文サポートが必要なので、彼の例からlet e: Events = Events.Pause;と書くことができます。 欠点はひどいものではありませんが、拡張列挙型が実装を隠すことができない場所です。 だからそれは一種のグロスです。

また、オプション1は悪い考えだと思います。 私は自分の会社でこの問題への参照を検索し、リンクされている2つのコードレビューを見つけました。どちらの場合も（そして私の個人的な経験では）、小さい列挙型の要素を大きい列挙型に割り当てる必要があることは明らかです。 。 私は特に、ある人が...を導入して、オプション2のように動作すると考え、次の人がより複雑なケースが機能しないときに本当に混乱する（またはas unknown as Events.Pauseのようなハックに頼る）ことを心配しています。

オプション2の動作を取得しようとする方法はすでにたくさんあります。このスレッドにはたくさんのスニペットがあり、さらに文字列リテラルの和集合を含むさまざまなアプローチがあります。 オプション1を実装する際の私の大きな心配は、オプション2を取得するための別の間違った方法を効果的に導入し、TypeScriptのこの部分を学ぶ人々にとってより多くのトラブルシューティングとフラストレーションにつながることです。

人々はどのような行動を望んでいますか、そしてその理由は何ですか？

コードは言葉よりも雄弁なので、OPの例を使用すると：

const BasicEvents = {
    Start: "Start",
    Finish: "Finish"
};
enum AdvEvents {
    ...BasicEvents,
    Pause = "Pause", // We added a new field
    Finish = "Finish2" // Oops, we actually modified a field in the parent enum
};
// The TypeScript compiler should refuse to compile this code
// But after removing the "Finish2" line,
// the TypeScript compiler should successfully handle it as one would normally expect with the spread operator

この例では、オプション2を示しています。 もしそうなら、私は必死にオプション2が欲しいです。

それ以外の場合は、他の文字列列挙型のように動作しない新しい種類の文字列列挙型を作成しています。これは奇妙で、ここでの提案の「単純さ」を損なうようです。

オプション2は少し不安であり、一歩下がって代替案を考えるのが最善かもしれないことに同意します。 これは、今日の列挙型に新しい構文や動作を追加せずにそれを実行する方法の調査です。

https://github.com/microsoft/TypeScript/issues/17592#issuecomment -449440944での私の提案は、最近最も近くなり、うまくいく可能性があると思います。

type Events = BasicEvents | AdvEvents;
const Events = {...BasicEvents, ...AdvEvents};

そのアプローチには2つの主な問題があります。

• TypeScriptを学んでいる人にとっては本当に混乱します。 タイプスペースと値スペースをしっかりと把握していない場合は、タイプを定数で上書きしているように見えます。
• Events.Pauseを型として使用できないため、不完全です。

以前、 https：//github.com/microsoft/TypeScript/issues/29130を提案しました。これは、（とりわけ）2番目の箇条書きに対処するものであり、それでも価値があると思いますが、確かに多くの微妙な点が追加されます。名前のしくみ。

両方の点に対処すると思う構文のアイデアの1つは、タイプを宣言する代替のconst構文です。

// Declares a value and a type at the same time with the same name (just like `enum` and `class` already do).
// Requires the right-hand side to be either a unit type or an object where all values are unit types.
// The JS emit would just take out the word "type" and leave everything else.
const type Events = {...BasicEvents, ...AdvEvents};
...
const e: Events.Pause = Events.Pause;
...
// The syntax could also make this pattern more ergonomic.
const type INACCESSIBLE = "INACCESSIBLE";
const response: {name: string, favoriteColor: string} | INACCESSIBLE = INACCESSIBLE;

これにより、列挙型がまったく必要ない世界に近づくことができます。 （私にとって、列挙型は、自明ではない放出動作を持ち、デフォルトで名目上の式レベルの構文であるため、TS設計の目標に反しているように常に感じていました。） const type宣言構文では、次のような構造的に型指定された文字列列挙型を作成します。

const type BasicEvents = {
  Start: 'Start',
  Finish: 'Finish',
};  // "as const" would be implicit for "const type" declarations.

確かに、これが機能するために必要な方法は、タイプBasicEventsがtypeof BasicEvents[keyof typeof BasicEvents]の省略形であり、 const typeのような一般的な名前の構文には焦点が絞られすぎている可能性があることです。 たぶん、別のキーワードの方が良いでしょう。 ひどいconst enumはすでに取られています😛。

そこから、（文字列）列挙型とオブジェクトリテラルの間の唯一のギャップは記名的型付けだと思います。 これは、 as uniqueやconst unique typeのような構文を使用して解決できる可能性があります。これらの構文は、基本的にこれらのオブジェクトタイプに対して、理想的には通常の文字列定数に対しても列挙型のような名目上の型付け動作を選択します。 これにより、 Eventsを定義するときにオプション1とオプション2のどちらかを明確に選択できます。 Eventsを完全に異なるタイプ（オプション1）にする場合は、 uniqueを使用します。 EventsとBasicEventsの間の割り当て可能性が必要な場合は、 uniqueを省略します（オプション2）。

const typeとconst unique typeを使用すると、既存の列挙型をきれいに結合する方法と、列挙型を1回限りではなくTS機能の自然な組み合わせとして表現する方法があります。

ここで何が起こっているのですか？ 😅

2017年からすごい🤪、これ以上のフィードバックが必要ですか？

これ以上のフィードバックが必要ですか？

ここで??? 提案は古いので、実装するだけではありません。

これ以上のフィードバックが必要ですか？

ここで??? 提案は古いので、実装するだけではありません。

はい。 どちらの方向かわかりませんでした。

もう一度読んで＃40998も見るのが最善の方法だと思います...列挙型はオブジェクトであり、スプレッドは列挙型をマージ/拡張する方が簡単だと思います。

言語デザインについて意見を述べるのに十分な資格はないと思いますが、通常の開発者としてフィードバックを提供できると思います。

この機能を使用したかった実際のプロジェクトで、数週間前にこの問題に遭遇しました。 私は@alangpierceのアプローチを使用することになりました。 残念ながら、雇用主に対する私の責任のため、ここでコードを共有することはできませんが、ここにいくつかのポイントがあります。

1. 宣言（新しい列挙型の型と定数の両方）を繰り返すことは大きな問題ではなく、読みやすさをそれほど損なうことはありませんでした。
2. 私の場合、列挙型は特定のアルゴリズムのさまざまなアクションを表しており、このアルゴリズムにはさまざまな状況のさまざまなアクションのセットがありました。 タイプ階層を使用することで、コンパイル時に特定のアクションが発生しないことを確認できました。これが全体のポイントであり、非常に便利であることがわかりました。
3. 私が書いたコードは内部ライブラリであり、異なる列挙型の区別はライブラリ内で重要でしたが、このライブラリの外部ユーザーにとっては重要ではありませんでした。 このアプローチを使用して、内部のすべての異なる列挙型の合計型である1つの型のみをエクスポートし、実装の詳細を非表示にすることができました。
4. 残念ながら、型宣言から合計型の値を自動的に解析する慣用的で読みやすい方法を理解できませんでした。 （私の場合、私が言及したさまざまなアルゴリズムのステップが実行時にSQLデータベースからロードされました）。 これは大きな問題ではありませんでしたが（解析コードを手動で作成するのは簡単でした）、列挙型継承の実装でこの問題に注意を払うことができれば便利です。

全体として、退屈なビジネスロジックを持つ実際のプロジェクトの多くは、この機能から多くの利益を得ると思います。 列挙型を異なるサブタイプに分割すると、型システムは、単体テストでチェックされる多くの不変条件をチェックできるようになります。型システムで誤った値を表現できないようにすることは、常に良いことです。

やあ、

ここに私の2セントを追加しましょう🙂

私の文脈

tsoaで生成されたOpenApiドキュメントを含むAPIがあります。

私のモデルの1つには、次のように定義されたステータスがあります。

enum EntityStatus {
    created = 'created',
    started = 'started',
    paused = 'paused',
    stopped = 'stopped',
    archived = 'archived',
}

これらのステータスのサブセットを取得するメソッドsetStatusがあります。 この機能は利用できないため、列挙型を次のように複製することを検討しました。

enum RequestedEntityStatus {
    started = 'started',
    paused = 'paused',
    stopped = 'stopped',
}

したがって、私の方法は次のように説明されます。

public setStatus(status: RequestedEntityStatus) {
   this.status = status;
}

そのコードで、私はこのエラーを受け取ります：

Conversion of type 'RequestedEntityStatus' to type 'EntityStatus' may be a mistake because neither type sufficiently overlaps with the other. If this was intentional, convert the expression to 'unknown' first.

今のところこれを行いますが、興味があり、これを見つけたときにこのリポジトリを検索し始めました。
一番下までスクロールした後、このユースケースを示唆する人は誰も見つかりませんでした（または何かを見逃した可能性があります）。

私のユースケースでは、EntityStatusがRequestedEntityStatusの拡張である理由がないため、列挙型から「拡張」したくありません。 より一般的な列挙型から「選択」できるようにしたいと思います。

わたしの提案

スプレッド演算子は拡張提案よりも優れていることがわかりましたが、さらに進んでこれらを提案したいと思います。

enum EntityStatus {
    created = 'created',
    started = 'started',
    paused = 'paused',
    stopped = 'stopped',
    archived = 'archived',
}

enum RequestedEntityStatus {
    // Pick/Reuse from EntityStatus
    EntityStatus.started,
    EntityStatus.paused,
    EntityStatus.stopped,
}

// Fake enum, just to demonstrate
enum TargetStatus {
    {...RequestedEntityStatus},
    // Why not another spread here?
    //{...AnotherEnum},
    EntityStatus.archived,
}

public class Entity {
    private status: EntityStatus = 'created'; // Why not a cast here, if types are compatible, and deserializable from a JSON. EntityStatus would just act as a type union here.

    public setStatus(requestedStatus: RequestedEntityStatus) {
        if (this.status === (requestedStatus as EntityStatus)) { // Should be OK because types are compatible, but the cast would be needed to avoid comparing oranges and apples
            return;
        }

        if (requestedStatus == RequestedStatus.stopped) { // Should be accessible from the enum as if it was declared inside.
            console.log('Stopping...');
        }

        this.status = requestedStatus;// Should work, since EntityStatus contains all the enum members that RequestedEntityStatus has.
    }

    public getStatusAsStatusRequest() : RequestedEntityStatus {
        if (this.status === EntityStatus.created || this.status === EntityStatus.archived) {
            throw new Error('Invalid status');
        }
        return this.status as RequestedEntityStatus; // We have  eliminated the cases where the conversion is impossible, so the conversion should be possible now.
    }
}

より一般的には、これは機能するはずです。

enum A { a = 'a' }
enum B { a = 'a' }

const a:A = A.a;
const b:B = B.a;

console.log(a === b);// Should not say "This condition will always return 'false' since the types 'A' and 'B' have no overlap.". They do have overlaps

言い換えると

列挙型の制約を緩和して、不透明な構造よりもユニオン（ 'a' | 'b' ）のように動作させたいと思います。

これらのアビリティをコンパイラに追加することにより、同じ値を持つ2つの独立した列挙型を、ユニオンと同じルールで相互に割り当てることができます。
次の列挙型が与えられます：

enum A { a = 'a', b = 'b' }
enum B { a = 'a' , c = 'c' }
enum C { ...A, c = 'c' }

そして、3つの変数a:A 、 b:B 、 c:C

• AはCのサブセットにすぎないため、 c = aは機能するはずです。したがって、Aのすべての値はCの有効な値です。
• c = bは機能するはずです。これは、Bが'a' | 'c'であり、どちらもCの有効な値であるためです。
• b = aは、 aが'b'と異なることがわかっている場合に機能します（これはタイプ'a'のみに相当します）
• 同様に、 a = bは、 bが'c'と異なることがわかっている場合に機能します。
• b = cは、 cが'b'と異なることがわかっている場合に機能します（これは'a'|'c'に等しく、これはまさにBです）

または、等式の比較に関しては、右側に明示的なキャストが必要な場合がありますか？

列挙型メンバーの競合について

スプレッド演算子で自然に感じたとしても、私は「最後の勝利」ルールのファンではありません。
キーと値の両方が同一でない限り、列挙型の「キー」または「値」のいずれかが重複している場合、コンパイラはエラーを返す必要があります。

enum A { a = 'a', b = 'b' }
enum B { a = 'a' , c = 'c' }
enum C {...A, ...B } // OK, equivalent to enum C { a = 'a', b = 'b', c = 'c' }, a is deduplicated
enum D {...A, a = 'd' } // Error : Redefinition of a
enum E {...A, d = 'a' } // Error : Duplicate key with value 'a'

閉鎖

この提案は、TS開発者が作業するのに非常に柔軟で自然であり、列挙型を実際に変更することなく、より多くの型安全性（ as unknown as Tと比較して）を可能にします。 列挙型にメンバーを追加する新しい方法と、列挙型を相互に比較する新しい方法を紹介するだけです。
どう思いますか？ この機能を実現できない明らかな言語アーキテクチャの問題を見逃しましたか？