したがって、最初の例では、次のように出力する可能性があります。

x && xy && xyz && xyzfoo

しかし、どういうわけか、x、y、z、およびfooをそれぞれ最大で1回評価する必要があります。

また、多くの場合、実際には&&を実行できません。これは、プリミティブにとって真実性が少し問題になるためです。

例えば：

"     "?.trim()?.indexOf("hello")

""を与えます。

したがって、型システムを利用しない限り、一般的なケースでは== $を使用してnullと明示的に比較する必要があります（これを見るとかなりクールです）。

おそらく、monadic-bind関数（JS出力にはきれいではありません）を発行するか、三項演算子（通常のJSの同等物に近い）で何らかの変換を使用することができます。 私は明らかに後者に少し偏っています。

それについてのesdiscussでの議論はほとんどありませんでした：

• http://esdiscuss.org/topic/the-existential-operator
• http://esdiscuss.org/topic/specifying-the-existential-operator-using-abrupt-completion

：+1：

実際に0 / ""を使用するかどうかについての正確なセマンティクスについてはおそらく意見の相違があるため、ES7（またはES8またはES9または...）で最初にこれを実装するのが理想的です。ここでの演算子の目的のための偽のプリミティブとしての

：+1：TypeScriptがESxxを待たずにこれを最初に取得することを望んでいます。

「？」のような単純でめちゃくちゃ便利なnull-safety演算子という事実。 そして「？：」ES6仕様に含まれていないということは、ES6仕様をまとめる人々が恥ずかしそうに頭を下げているべきであることを意味します。 これは非常に単純で明白なことなので、それを組み込まないことは率直に言って非常識です。 ほとんどの現代言語がこれらをサポートする理由があります：それらは不可欠です。

これは現在の仕様からの逸脱であると私は理解しています（現在の仕様はこれを省略しているほど近視眼的であるため）。 しかし、それはとてつもなく便利なので、この単一の逸脱は正当化されると思います。 TS開発者の大多数（VAST）は、これが最終的にES仕様に追加された場合、またはそのときに、実装への小さな変更の影響を受けません。 これが提供する大きなメリットは、ごく一部の開発者に将来的に影響を与える可能性がある価値があります。 そして、笑えるほど遅いES仕様プロセスを考えると、これは（少なくとも）数年間はまったく問題になりません。

私はbrain428に完全に同意します

@ brian428ここでの問題は、その演算子がES7に実装されている可能性があるため、typescriptが最終的なES7の仕様とは異なる仕様になっている場合、誰も満足しないことです。

ここでの問題は、その演算子がES7に実装されている可能性があるため、typescriptが最終的なES7の仕様とは異なる仕様になっている場合、誰も満足しないことです。

TypeScriptは、ESの方向性に影響を与えるための有用なテストベッドとなるため、将来のESバージョンに_潜在的に_（またはそうでない）可能性のある機能を実装する方が、より積極的なアプローチだと思います。

TypeScriptの影響を受けているESディスカッションの例を次に示します。

コンストラクターのパラメーターの1つにプライベートプレフィックスを介して宣言および初期化するTypeScript ...オプションは、多くの開発者に役立ちます

さらに、ESがTypeScriptにすでに存在する機能を採用することは確かに可能ですが、セマンティクスは異なります（たとえば、モジュールの動作方法など）。

ESがTypeScriptにすでに存在する機能を採用することは確かに可能ですが、セマンティクスは異なります

これは最悪のシナリオであると広く考えていることに注意してください。 TypeScript 1.0を宣言する前に、ES6のモジュールを完成させたかったのですが、委員会のスケジュールの遅れにより、それができませんでした。 これは、繰り返されるのではなく、避けるべきものです。 ES7 +になる可能性が最大0％（タイプアノテーションなど）であるか、簡単に定義されたセマンティクス（太い矢印が2である場合など）で機能する可能性が最大100％の機能をヒットさせたいと考えています。数年前）。 新しいオペレーターは厄介な中間に陥る可能性があります。

最悪の場合、ES7が異なる場合、コンパイラフラグはレガシーTS実装をサポートし、猶予期間を提供できますか？ これと明確な移行ドキュメントを組み合わせることで、開発者は新しい標準への簡単なルートを提供できるはずです。

最終的に、そのような機能の使用は、めちゃくちゃ便利ですが、開発者にとって必須ではありません。 TSは、その使用法の潜在的な将来の影響を初日から十分に明らかにする必要があります。 潜在的なマネージドリファクタリングのアイデアは好きではありません。使用しないでください。 おそらく、このメッセージを強制するためのオプトインコンパイラフラグですか？

TSはESに影響を与えたいと思って暴れるべきではありませんが、このような小さな孤立したケースでは、TSが完全に恥ずかしがるのは残念です。

たぶん、これに関するストローマンの提案をまとめて、-harmonyフラグ（またはそのようなもの）の背後にリファレンス実装を置くことができます。 そうすれば、この機能のES7開発を推進できます。

繰り返しのルックアップによる副作用を防ぐために、コンパイラーは一時変数を出力する必要があります。

($tmp0 = x, $tmp0 === void 0 ? void 0 : 
    ($tmp1=$tmp0.y,  $tmp1 === void 0 ? void 0 : 
        ($tmp2 = $tmp1.z,  $tmp2 === void 0 ? void 0 : $tmp2)))

または、 Proxyに基づくメモ化メンブレンを使用します。

カテゴリの観点からは、これはプロパティルックアップに適用されるモナドである可能性があるため、すべてのプロパティルックアップが未定義を返す可能性がある言語にとっては非常に自然な機能です。 ES7が上記のコードで説明されているもの以外のセマンティクスを採用した場合は驚きます。

codeplexの問題にはかなりの数の票がありました（61）

atom-typescriptにatomを使用する手間を軽減するために、これは本当にひどく必要です。

これは、coffescriptコードでは非常に慣用的です（ただし、決定論が厄介な?よりも優れているので人気がないようにしたいと思います）。 coffescriptファイル、特にスペースペンのようにDOMと直接連携するファイル（ビューが破棄された後、またはビューがアタッチされる前に関数を実行できるファイル）を開くと、膨大な数の?の使用法が見つかります。 たとえば、このファイルには16 https：//github.com/atom-community/autocomplete-plus/blob/f17659ad4fecbd69855dfaf00c11856572ad26e7/lib/suggestion-list-element.coffeeがあります

繰り返しになりますが、これが必要なのは好きではありませんが、JavaScriptの状態であり、100万ドルよりも?の方がいいですif( && fest ) { then }

しかし、コードを読みやすくするために本当に必要です。 また、XHRが完了し、ダイジェストループが角度で実行されるのを待っているときに、これが「必要」になることもよくあります。

さて、スレッドを読んで、なぜ待っているのかを確認しました。 私は_ため息_を理解しています。

we'd have to somehow make x, y, z, and foo each evaluate at most once.

Coffeescriptはいくつかの最適化を行います。たとえば、中間アクセス結果を保存します。

typeof foo !== "undefined" && foo !== null ? (ref = foo.bar) != null ? ref.baz() : void 0 : void 0;

（私はundefinedチェックがtypescriptには不要だと強く感じています：typescriptによってvar initタイプチェックが必要なので）

+1

今日のニュースでは、ダートはそれに対する公式のサポートを受けています： https ：//github.com/gbracha/nullAwareOperators/blob/master/proposal.md

非常に重要な機能。

おそらくオフザウォールのアイデアですが、キー付きプロパティアクセスで機能を処理しても問題ないと誰もが判断した場合、この機能のコード生成は副作用なしで非常に簡単に実行できます。

if (aaa?.bbb?.ccc) {}

にコンパイルできます

if (__chain(aaa, "bbb", "ccc")) {}

__chain関数は、 __extendsと同様に発行する必要があります。 __chain関数は、 arguments配列を反復処理するだけで、次のメンバーがinstanceof Objectでない場合、またはメンバー名が含まれていない場合にnullを返します。 関数呼び出しは、配列をパラメーターとして渡すことで（そして、内部.apply()を使用して）処理できるため、...

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

にコンパイルできます

if (__chain(aaa, "bbb", "ccc", [1, 2, 3])) {}

これにより、長いチェーンの場合でも、生成されたJSがかなり慣用的になります。

明らかに洗練が必要です...しかし、おそらくここに何かがありますか？

aaa?.bbb?.ccc?がa.b.cの値を返す場合、すべての小道具が存在し、それが関数である場合は、できませんでした

if (aaa?.bbb?.ccc?(1, 2, 3)) {}

にコンパイルする

if (__chain(aaa, "bbb", "ccc")(1, 2, 3)) {}

？

@metaweta ：あなたのソリューションはvoid 0をチェックするだけです...そのような種類の機能の目的を打ち負かしませんか？

これはどうですか：

var result = one?.two?.three;

生成：

var $a, $b, $c;
var result = $a = one, $b = $a ? $a.two : void 0, $b ? $b.three : void 0;

私はこれがすべてのケースを処理すると確信しています。 関数呼び出しにはおそらくinstanceof Functionチェックが必要です。

（予期しないローカル変数が放出されるというここでのマイナーな欠点...多分IIFEでラップされる可能性があります）

@ kevinb7 ： cccが関数でない場合はどうなりますか？ 説明したコードでは、 __chainは常に有効な関数を返す必要があります。そうしないと、TypeErrorが発生します。

@ Back-ioプロパティが存在しない場合、ルックアップはundefined === void 0を返します。ソリューションは、空の文字列やゼロなどの誤った値のプロパティのルックアップに失敗します。

@metaweta ：いいえ、そうではありません：http： //jsfiddle.net/25LppbL6/

また、一部の人々のリンターがそれに対して警告しているという事実のために、TSチームは緩い平等を使用することに夢中ではないと思います。

@ Back-ioはい、そうです：http： //jsfiddle.net/25LppbL6/2/

@ Back-io nullに関しては、a？.bの意図されたセマンティクスが何であるかわかりません。 「プロパティbが定義されている場合はそれを使用する」の場合、私のコードはほぼ正しいです。 nullを取得する唯一の方法は、nullに割り当てられている場合です。これは、存在しないプロパティのルックアップが未定義を返すためです。 プロパティは存在するが未定義に設定されている場合はキャッチできません。 完全に正しいためには、void 0 === undefinedと比較する代わりに、Object.hasOwnProperty（）でチェックします。

セマンティクスが「プロパティbが真実である場合はそれを使用する」である場合、コードは問題なく、JSイディオムとある程度一致します。

うーん...何かが足りない場合を除いて...フィドルに加えた変更は、私が正しいことをさらに証明します... var resultは、3つのケースすべてでまだundefinedです。 そして、原始的なプロトタイプを拡張することによって、あなたがどのようなケースを提起しようとしているのかわかりません...

この機能の動作は、エラーを生成するのではなく、 void 0で短絡することになると確信しています。 （メンバーが見つからない場合は常にvoid 0を返す必要があるという上記のアイデアが気に入っています）。

''?.toStringの意図された出力は何ですか？

@ kevinb7 ：cccが関数でない場合はどうなりますか？ 説明したコードでは、__ chainは常に有効な関数を返す必要があります。そうしないと、TypeErrorが発行されます。

いい視点ね。

@metaweta ：ほとんどの人がtoString関数への参照を期待していると思いますので、あなたのポイントがわかります。0、false、のプロトタイプメンバーにアクセスしている場合は多少壊れます。また ''。

：+1：
Angular2はテンプレート構文にエルビス演算子を追加しました

@metaweta ：

''？。toStringの意図された出力は何ですか？

''?.toString()を意味する場合は、次のようになります。

if ('' != null) {
  ''.toString();
}

サンプル

たぶん、これについてストローマンの提案をまとめることができます

@ kevinb7すでに存在します： http ：//wiki.ecmascript.org/doku.php？id = strawman：existential_operator

特別な場合としてPropertyAccessExpressionの上にこれを実装するためにいくつかの簡単なテストを行いましたが、（ .のように左結合ではなく）右結合であるために?.が本当に必要なため、うまくいきませんでした. ）そうでないと、エミッターが不必要に複雑になります。

これを反映したBrendenEichによるコメントがここにあります。

特別な場合としてPropertyAccessExpressionの上にこれを実装するためにいくつかの簡単なテストを行いましたが、本当に必要なためうまくいきませんでしたか？ （のように左結合ではなく）右結合である必要があります。そうしないと、エミッタが不必要に複雑になります。

@basarat詳しく教えていただけますか？ 右結合と左結合の違いの例?.は、私にとって非常に役立ちます。

@zlumer

右結合と左結合の違いの例？ 私にとって非常に役に立ちます。

.は結合性のままなので、式foo?.bar?.bazはASTになります（ ?.を同じように扱う場合）：

                    // foo.bar.baz = PropertyAccessExpression
                    //   .expr foo.bar =  PropertyAccessExpression
                    //     .expr foo = Identifier
                    //     .name bar = Identifier
                    //   .name baz = Identifier

必要なJavaScriptの放出は

foo != null ? (ref_1 = foo.bar) != null ? ref_1.baz() : void 0 : void 0;

ASTに次のようなものがある場合、この放出を行うのは（特に_再帰的に_）簡単です。

                    // foo.bar.baz = PropertySafeAccessExpression
                    //   .name foo =  Identifier
                    //   .expr bar.baz = PropertySafeAccessExpression
                    //      .expr bar = Identifier
                    //      .name baz = Identifier

_最初のASTをJavaScriptに変換する方法_を考えてみてください。複雑さがより明確になります。 これが役立つことを願っています：rose：

@ zlumer 、 @ basaratが言ったことに追加するために、例1 + 2 + 3を出します。

解析するとき、これらの操作のどれが最初に行われるかを決定する必要があります。

+が左結合である場合、これは((1 + 2) + 3)として解釈されます。

+が右結合である場合、これは(1 + (2 + 3))として解釈されます。

これが実際に違いを生むかどうか疑問に思うかもしれません。 JavaScriptではそうなるでしょう！ "hello" + 2 + 3の例を考えてみましょう。

• 左結合： (("hello" + 2) + 3) => ("hello2" + 3) => "hello23"
• 右連想： ("hello" + (2 + 3)) => ("hello" + 5) => "hello5"

（記録のために、JavaScript / TypeScriptは+演算子に左結合性を使用します。）

@ basarat 、 @ BrendanEichが言ったことの私の理解（そして私が間違っていれば彼は私を訂正することができます-pingを申し訳ありません！）は?.が正しい連想であるということではありませんが、CoffeeScriptの特殊なケースのプロパティはにアクセスします?.が右連想である権利。 たとえば、解析します

o.p?.q.r.s

なので

((o . p) ?. (q . (r . s))) # or something close to this

それ以外の

((((o . p) ?. q) . r) . s)

放出しやすいからです。

私たちのASTは、適切なセマンティック分析に適している必要があるため、このニーズに合わせて、放出手順を少し複雑にすることができます。

@ basarat @ DanielRosenwasser説明ありがとうございます。 今のところ私はそれを理解していますが、私はまだ一つのことについて確信がありません。
左結合?.は非常に明白であり、予想されます。

foo?.bar?.baz

なる（約）：

var ref = ((ref = foo) == null) ? null : ((ref = ref.bar) == null) ? null : ref.baz;

しかし、右結合?.がどのように機能するかはまったくわかりません。 例を挙げていただけますか？

しかし、私は、右連想がどのようになるのか、まったく理解していません。 仕事。 例を挙げていただけますか

@zlumer実行時の動作は結合性のままになります。 DanielRosenwasserも明らかにしたように、私はASTについて話していました： is not that ?. is right-associative, but that CoffeeScript special cases property accesses on the right of the ?. to be right-associative 。

私たちのASTは、適切なセマンティック分析に適している必要があるため、このニーズに合わせて、放出手順を少し複雑にすることができます。

@DanielRosenwasserフィードバックをありがとう：rose：

@basaratありがとう、突然すべてが明らかになりました：smiley：

@basaratの2月のコメントと同様に、私は.... _sigh .. ..

ただし、考えてみると、このユースケースの99％は、オブジェクトへのnullポインターをチェックすることです。 率直に言って、 xがnumber $の場合、誰がx?.b?.c $を実行しますか？ オブジェクトについて話していないときの_long_チェーンの実際のユースケースは多くありません（ stringを除いて）。 ショートチェーンの場合、 x && x.bまたはx === 0 ? null : x.bで生活できると思います。

では、 ?.はオブジェクトタイプでのみ機能すると言うことができますか？ その他のタイプは構文エラーをスローします。 また、チェーン内での関数呼び出しを禁止します。

次に、すべてがa && a.b && a.b.cに転記されます。

@schungxチェーンのメンバーが「任意の」タイプの場合はどうなりますか？ 完全に禁止しますか？ それとも、それを通過させて、最高のものを期待しますか？

さて、私の提案？ 完全に禁止します。 地獄のようにエレガントではない、私は知っている... :-)

しかし、私の理論的根拠：

1. これは速記なので、誰かがanyを使用している場合は、速記を使用してください。
2. 誰かがTypeScriptを使用している場合、おそらくその人はタイピングサポートにそれを使用しているので、うまくいけば、彼/彼女は周りに多くのanyを持っていないでしょう！
3. anyは本当に注意して扱う必要があります。 anyのような柔軟なタイプでこのようなショートハンドの使用を許可することは、実際にバグが発生することを求めています。 私の意見では、 anyは可能な限り制限する必要があります。 それはCの(void *)のようなものです-あなたが核兵器を手渡されたという事実は、あなたができるという理由だけでそれを誘発しなければならないという意味ではありません！

これは素晴らしいオペレーターでしょう！ 特にES6 / ES7 / TypeScriptの場合

var error = a.b.c.d; //this would fail with error if a, b or c are null or undefined.
var current = a && a.b && a.b.c && a.b.c.d; // the current messy way to handle this
var currentBrackets = a && a['b'] && a['b']['c'] && a['b']['c']['d']; //the current messy way to handle this
var typeScript = a?.b?.c?.d; // The typescript way of handling the above mess with no errors
var typeScriptBrackets = a?['b']?['c']?['d']; //The typescript of handling the above mess with no errors

しかし、私はもっと明確なものを提案します-混乱しないように？ から？ b：a？.bステートメントを含むcステートメント：

var doubleDots = a..b..c..d; //this would be ideal to understand that you assume that if any of a, b, c is null or undefined the result will be null or undefined.
var doubleDotsWithBrackets = a..['b']..['c']..['d'];

角かっこ表記については、角かっこ以外を使用すると他の点と一致するため、1つではなく2つの点をお勧めします。 したがって、プロパティ名のみが括弧を介して静的または動的になります。

2つのドットは、そのnullまたは未定義がさらに処理を停止し、式の結果がnullまたは未定義であると想定することを意味します。 （dはnullまたは未定義になるため）。

2つのドットにより、何が起こっているのかを理解できるように、より明確で、より見やすく、よりスペース的になります。

これも数字を台無しにすることはありません-同じ場合ではないので、例えば

1..toString(); // works returning '1'
var x = {};
x.1 = {y: 'test' }; //fails currently
x[1] = {y: 'test' }; //works currently 
var current = x[1].y; //works
var missing= x[2].y; //throws exception
var assume= x && x[2] && x[2].y; // works but very messy

番号2のオプションについて：どちらを採用できるかというあなたの電話ですが、既存のルールとの互換性のために最初のものをお勧めします！

1. 現在のように失敗するはずです（ x.1.y == runtime error ）

var err = x..1..y; // should fail as well, since 1 is not a good property name, nor a number to call a method, since it's after x object.

1. Number.prototypeからプロパティを呼び出す番号ではないことを理解しているため、機能するはずです

var err = x..1..y; // should work as well, resulting 'test' in this case
var err = x..2..y; // should work as well, resulting undefined in this case

動的な名前の場合：

var correct1 = x..[1]..y; //would work returning 'test'
var correct2 = x..[2]..y; //would work returning undefined;

皆さんはどう思いますか？

PS foo?.barおよびfoo?['bar']構文も機能します。

ただし、現在の? :演算子と?.の両方を使用すると、同じ行で非常に混乱する可能性があります。

例： ?.と?['prop']を使用する

var a = { x: { y: 1 } };
var b = condition ? a?.x.?y : a?.y?.z;
var c = condition ? a?['x']?['y'] : a?['y']?['z'];

ダブルドット..と..['prop']とは対照的に

var a = { x: { y: 1 } };
var b = condition ? a..x..y : a..y..z;
var c = condition ? a..['x']..['y'] : a..['y']..['z'];

どちらがあなたにとってより明確に見えますか？

とても興味深い。 ：+1：

私見、2つのドットはもっと混乱します。 2つのドットが範囲を表す言語（例： 1..4 ）があり、TypeScriptは将来この機能を追加する可能性があります。

疑問符には、不確実性または条件付きの意味的な意味もあり、2つのドットは同じ意味を伝えません。

@schungx十分に公平ですが、次のような奇妙な可能性に役立ちます： a?['b']またはこのa?() 。

+1 ?

a?['b']とa?()は、coffeescriptでうまく動作し、私には似合います。

しかし、繰り返しになりますが、私はコーヒースクリプトを盲目にしているだけかもしれません。

+1 Rubyは、実存演算子https://twitter.com/mikepack_/status/657229703443451904を実装しました。 Typescriptは、特定の構文に関係なく、これも必要とします。

これにより、コードがよりクリーンになります👍

+1これが必要です！

よろしくお願いします？ C＃のように演算子

+1私は長い間これを見逃してきました

+1
書くのがとても醜い：someVariable && someVariable.someMember
あなたが書くことができるとき：someVariable？.someMember

+1、これは素晴らしいでしょう....（私にとって最も欲しかった機能）

+1、それは良い考えです！
ただ、オブジェクトが複雑な場合、式は？でいっぱいになります。 各プロパティ（var result = myValue？.a？.b？.c？.d？.e;）の後、最後のプロパティ（var result =？myValue.abcde;）の値を受け取る必要がある場合。

+ 1-これは間違いなくCoffeeScriptの最大の機能の1つであり、コードの多くをCSからTSに変換した後、私のチームで最も望まれるTypeScript機能です。

+1ただし、これは複雑すぎます。

var x = { y: { z: null, q: undefined } };
var z: x|y|z = x?.y?.z;

私はこれが好き：

var x = { y: { z: null, q: undefined } };
var z: z|void = x?.y?.z;

x?.y?.zのタイプは、常にzフィールドのタイプです。 もちろん、型はnull可能である必要があり、実際の値はnullである可能性があります。 null以外の場合は、 zフィールドのタイプである必要があります。

+1これは、大規模で複雑なJSプロジェクトの開発を容易にするというTypescriptのビジョンとうまく調和します。

これに関する更新はありますか？ これは、この機能を検討するためにコミュニティが投票した場合ですか？ または、検討されましたが、エンジニアリング上の課題がいくつかありますか？

ECMAScript委員会からの何らかの提案がなければ、新しい式レベルの構文を導入することは危険であるため、これまでのところ更新はありません。

https://github.com/Microsoft/TypeScript/issues/16#issuecomment-57645069を参照してください。

これが実存的演算子に関するより最近の議論です（たくさんの考えがありますが、多くの行動のようには見えません）：

• 存在演算子/ヌル伝搬演算子

ESに「+1」を付けるには、どこに「+1」と書く必要がありますか？

@msklvsk ESDiscuss

今のところこれを閉じます。 式レベルでこれを必要とするTypeScript固有のものは実際にはないため、この種の大きな演算子の変更は、ここではなくES仕様委員会で行う必要があります。

これを再評価するための一般的なトリップワイヤーは、次の段階に到達する具体的なES提案、またはこの機能が長期間発生しないというES委員会からの一般的なコンセンサスです（これにより、独自のセマンティクスを定義し、合理的にすることができます）彼らが「勝つ」ことを確認してください）。

人生は最悪

スタンドアロンの削除：+1：s。 GitHubリアクション機能を使用するか、最寄りのTC39担当者に花やキャンディーを送ってください。

私がcoffeescriptとSwiftでそれに慣れたら、後戻りはできません。 TSは現在のところ、私には死んでいます。

@algesten言語自体を考慮すると、 swiftについては同意できますが、長期的なcoffescriptのサポートについてはわかりません（本番プロジェクトではCoffeScriptを使用しています）。 2016年6月の言語分析のトレンドについては、このように確認することに同意するかもしれません。ここでは、最近coffescriptがどうなっているのかを明確に確認できますが、 TypeScriptは過去数年間で最も急速に成長しています。

TypeScript：GoまたはSwift以外で、私たちが近年観察した最も急速に成長している言語はTypeScriptです。 マイクロソフトが支援するJavaScriptスーパーセットとAngular2ファウンデーションは、2四半期連続で大幅な進歩を遂げ、＃31から＃26に跳ね上がりました。 これは、トップ30言語の中で最大の単一の変更であり、全体で2番目に大きなジャンプでした（Standard ML、7スポット）。 実際、＃26では、TypeScriptはErlangと結びついており、Powershellの後ろに1つ、CoffeeScriptの後ろに4つあり、トップ20のすぐ外にあります。言語が直面している問題は、成長できるかどうかではなく、勢いがあるかどうかです。次の2〜3四半期でトップ20にランクインし、その過程でCoffeeScriptやLuaなどを飛躍させます。

2014年まで、 coffescriptの傾向は、ここで見ることができるようにポジティブ以上でした。それは、衰退が始まったときです。

新しいtypescript2.0の厳密なnull（未定義）チェックでは、関数チェーンを使用できないため、これは必須です。

これは、ECMAScriptの次のバージョンに含まれているはずです。 これがTypeScriptよりもバニラJavaScriptでさらに役立つことを考えると、実装が真実のチェックではなく、未定義またはnullのチェックになることを考えると、TC39が追加するのは簡単なはずです。

単純な実装とJavaScriptで慣用的な実装は、nullまたはundefinedのいずれかに遭遇したときに短絡し、undefinedを返すことです。

@bterlsonこれは意味がありますか？ そのような提案が受け入れられる確率はどのくらいですか？

typescriptの大きな利点の1つは、「未来は今日あなたに与えられる」ということです。 これは私が驚いた機能の1つであり、まだそこにはありません。

関数チェーンが一般的なイディオムであり、厳密なnullチェックが行われなくなったら、すぐに追加されることを願っています。 演算子が追加されました。

TS 2のすばらしいnullチェックにより、必要なものが必要になりました。

このスレッドを読んで、これがメンテナからもっと注目されていないことにちょっと驚いています。

理想的な世界では、TypeScriptはESの道を先導するべきであり、逆ではありません。 真面目な話ですが、TSチームがESxが機能や構文を提案して完成させるのを常に待っていたとしたら、TypeScriptはどこにあるのでしょうか。

他の人が指摘しているように、この構文は実際には「必須」です。 これまでのところ、このスレッドでいくつかの良い提案を受け取っています。 実装はこれらの期待に一致するはずだと思います。

• 一般に、式a?.bは、 a.bが有効である場合にのみ、コンパイル時に有効である必要があります。
• チェーン内の各式を1回だけ評価する必要があります。
• 短絡しているはずです。
• 実行がnullまたはundefinedの値を持つ式の途中に達した場合、その値が戻り値になります。

ESがそれを指定するときに不一致につながる可能性のある部分は何だと思いますか？

a?.bの場合、既存の（そして将来の？）構文との競合は見られません。 パーサーがトークン?.を見つけた場合、それを「安全なナビゲーション演算子」として扱うことができます（@cervengocで説明されているように期待されます）。

構文の競合は、 a?(b)とa?[b]を許可する場合にのみ発生します。これは、これらが3項の?:演算子式の開始としても解釈される可能性があるためです。 しかし、初心者にとっては、これらは脇に置いておくことができ、 a?.b構文だけをサポートすることで、すでに多くの開発者を満足させることができると思います。

理想的な世界では、TypeScriptはESの道を先導するべきであり、逆ではありません。

式レベルの構文に関しては、まったく同意しません。 ある理由で標準を推進する委員会があります。1人のプレーヤーによる1回限りのアクションがJavaScriptの将来を一方的に決定できるようにするためではありません。

他の人が指摘しているように、この構文は実際には「必須」です。

これがTypeScriptの必需品である場合、JavaScriptの必需品でもあります。 繰り返しになりますが、ECMAScript委員会に懸念を持ってください。

ESがそれを指定するときに不一致につながる可能性のある部分は何だと思いますか？

少なくとも、これらの値に遭遇したときに構文がnullまたはundefinedに短絡するか、常にundefinedに短絡するかについては意見の相違があると思います。 また、ある形式の括弧で囲まれた構文がサポートされているかどうかについても、いくつかの論争があります。 a?.b.cの振る舞いが何であるかという問題もあります。 ?. vs .? vs a.b?の質問もあります。 これがdelete演算子にどのような影響を与えるかという問題があります。

これに関するESDIscussスレッドは、100コメントを超える長さです。 あいまいさの欠如はありません！ 1つの例を単独で見て、コーナーケースがたくさんあるはずがないと考えるのは簡単です。 がある。 これが、TC39でまだ誰もこれを支持していない理由であり、動作の仕方について多くのあいまいさがある機能を急いで追加しない理由でもあります。

申し訳ありませんが、言及されたスレッドを読んでいませんでした。もっと見るために間違いなくそれを見ていきます。

これは少し違った見方をしています。 委員会について、私の正直な意見では、これがJavaScriptが決して_良い_ではない最大の理由の1つです。 ほんの一例として、私が見た中で最も成功したソフトウェアの多く（Total CommanderやIrfanViewなど）は、*委員会ではなく1人の担当者によって保守および設計されているため、成功しています。もちろん、これは完全ではありません。正しい例ですが、たとえば、あなただけが完全なES6を設計したとしたら、世界は今より良い場所になるとほぼ確信しています。

また、あなたが言及したあいまいさは、99％の「理論的」なものであり、開発者側からは無関係です。 nullまたはundefined $のどちらが返されるか、誰が気にしますか？ 1つ選ぶだけで、そのように使用します。

全体として、あなたとその委員会は私たちのほとんどとは異なる側にあり、その側からのものは通常、実際よりも複雑です。 そして、これは控えめに言っても、いくらかの逆生産性につながる可能性があります。 個人的には受け取らないでください。しかし、一般的な私の経験によれば、会議室から頻繁に出て、コードを見る方がよい人もいます。

もちろん、不快感はありません。個人的には何も取らないでください。私を含む多くの開発者のクライアント側開発に革命をもたらしたので、私はあなたとすべてのTSチームに大きな敬意を表します。すべての作業に感謝します。 私たちが推測するこの特定のものに少しがっかりしています。

最後にもう1つ考えました。 私は前述のESスレッドを実行しましたが、1つ確かなことがあります。それは、彼らがそれを複雑にしすぎているということです。 彼らはあらゆるシナリオに適したものを設計したいと考えています。

私は個人的に、条件付きメンバーアクセス演算子に完全に満足して満足しています。 条件付き呼び出し、条件付きインデックス署名は必要ありません。有効なJSコードであるすべての派手なシナリオをサポートする必要はありません。 それで全部です。 しかし、代わりに、彼らはそこに座って、すべてを一度に行う方法について話し合う可能性があります。これは素晴らしい計画ですが、結局のところ何もありません。

全体として、あなたとその委員会は私たちのほとんどとは異なる側にあり、その側からのものは通常、実際よりも複雑です。

ライアンやTC39の本当のステータスを正確に反映しているとは思いません。 RyanとTypeScriptチームは、TypeScriptの非常に明確な設計目標を設定しました。 当初の、そして今なお非常に現在の目標の1つは、TypeScriptがJavaScriptのスーパーセットであるということです。 人々が望んでいる言語ではありません（例：Dart、Haxe）。 構文に関しては、TypeScriptチームは、構文を事前に発明するコスト（モジュールなど）を苦労して学びました。 提案されたES構文がTypeScriptが使用する構文と完全に互換性がない場合、クラスのプライベートメンバーとの課題にも真っ向から向かいます。 なんで？ 言語の実行時の課題を考えると、表面上は複雑に見えないかもしれないことを達成することは不可能だからです。

私の意見では、TC39はJavaScriptを「保存」しています。 ES4は、優れた革新的なアイデアが不足していたためではなく、インターネットを破壊するために放棄されました。 TC39は形になり、彼らは彼らの議論と彼らがどのように決定を下し、ES4に非常に似ているがインターネットを壊さなかったES2015を私たちに提供したかについて共有し、完全にオープンになりました。 基本的に、10年前のコードを問題なく実行するJavaScriptランタイムがありますが、言語の多くの重要な改善をサポートしていることは驚くべきことです。 ES2016は嵐の前の落ち着きでした。 ES2017には、「合理的な」量の機能と変更があり、正しい方向に向かう明確な管理プロセスがあります。

ですから、私の意見では、物事の「異なる側」にいることは明らかにうまくいきました。 これは、「必須」機能の利便性に勝るものです。

@kitsonk私は「別の側面」を否定的に意味していませんでした。特に、TypeScriptまたはES6に入れられた作業を低下させるつもりはありませんでした。 さらに、TypeScript IMOの最も優れている点は、明確な設計目標があり、他の多くのオープンソースのものと同様に大混乱になることから十分に保護されていることです。

この機能は、天才的な人々のグループが、単純な方法ではなく、物事を考えすぎて複雑にし、呼び出しやインデックス署名をサポートしないなどの制限を受け入れるという明確な例であることを伝えたかっただけです。 。そのフォーラムの誰かが、割り当てでこの構文を使用することを提案しましたが、これはちょっとクレイジーです。 この意味では、この現象は逆効果だと思います。

たとえば、個人のメンバーが最終的なES6の概念と互換性がなくなるのは、あなたの側では苦痛だと理解しています。 しかし一方で、私たちはそれを持っていました。 ES6のずっと前。 そして、それが私たちの側からの要点です。 大まかに言えば、適切なコードをどのように発行するかは気にせず、ただ喜んで使用しています。 モジュール、およびすべてと同じです。 私たち（または少なくとも私）は、あなたがそれについて話しているような苦痛を見ていませんでした。私たちは常にプライベートメンバーやモジュールに満足していました。

この特定の機能は、私が読んだCoffeScriptにあります。 なぜ私たち、単純な開発者は、プラットフォーム/ライブラリ/プラグインなどを選択するときに常に妥協しなければならないのですか？ 私はいつもという意味です。 これはちょっと面倒です。 ここには、他のすべての参加者（ESを含む！）を完全に置き去りにし、クライアント側の開発の大部分に革命をもたらし、この「シンプルな」機能（少なくともメンバーアクセス部分を意味します）、ESがこれにコミットするまで実装されないと聞いています。

今日のTC39ミーティングで、この機能がステージ0からステージ1に移行したことを簡単に説明したいと思います。

関連するコミット： https ：//github.com/tc39/proposals/commit/cb447642290a55398d483f5b55fb7f973273c75d
会議の議題： https ：//github.com/tc39/agendas/blob/master/2017/01.md

おお！ それは巨大です！

https://github.com/claudepache/es-optional-chainingへのリンクも価値があります

私がここで見るいくつかの「驚き」（私が同意しないと言っているのではなく、以前にこれを行っていたとしたらおそらく違ったやり方で行ったであろうことだけです）：

• nullはa?.b式から生成されません： aがnullの場合、代わりにundefinedが生成されます
• 〜連鎖ドットでの伝播：$ bおよびcプロパティがundefinedの場合、$ a?.b.c.dはスローされません〜ライアンは読み取ることができません
• 〜親の存在下での伝播： bが定義されていない場合、$ (a?.b).cでさえスローされません〜ライアンは読み取ることができません
• 〜伝播はメソッド呼び出しでも発生します：$ c呼び出しがnullを返す場合、$ a?.b.c().dはundefinedを返します〜ライアンは読み取ることができません
• delete演算子がサポートされています
• ブラケット構文a?.[x]がサポートされています
• メソッド呼び出し以外の場合でも、関数呼び出し構文func?.(...args)がサポートされています（！）

今からステージ2までの間にこれらの分野で変化が見られると思います。

私はcoffeescriptがそれを正しく理解したと思います。

bが未定義の場合、a？.bcがスローされます。

a？（）とa？[0]はどちらも良いです。

• 連鎖ドットでの伝播：bおよびcプロパティが定義されていない場合、a？.bcdはスローされません
• 親の存在下での伝播：bが定義されていない場合でも（a？.b）.cはスローされません
• メソッド呼び出しでも伝播が発生します。c呼び出しがnullを返す場合、a？.bc（）。dはundefinedを返します。

それらの点は私には正確ではないようです。 提案から：

a?.b.c().d      // undefined if a is null/undefined, a.b.c().d otherwise.
                // NB: If a is not null/undefined, and a.b is nevertheless undefined,
                //     short-circuiting does *not* apply

うわー、私はそれを完全に読み違えました。 あなたが正しい。 更新

元の提案からの@algesten ：

a?.()

b?.[0]

甘い。 その場合、演算子は?.のようになります。

ここでいくつかの追加の会話が行われています： https ：//github.com/estree/estree/issues/146

うまく適用できる引用：«単純なことを簡単にし、難しいことを可能にする»。 したがって、おそらく、最も一般的なケースを適切にサポートし、複雑な/まれなケースを（少なくとも最初は）スキップしながら、より長い（既存の）構文で「手動で実行」することを許可します。

ちょうど私の2セント

let a = b?.c?.d?.e;

に：

let a;
try{
   a = b.c.d.e;
}catch(e){
   a = undefined;
}

@cedvdbのまったく異なるセマンティクス-ゲッターでスローされた例外は合体を引き起こしてはなりません

@RyanCavanaughええ..私はこれを考え抜かなかった。

これは現在実装のレーダーにありますか、それともTSチームはES提案がさらに進むのを待ちますか？

それは私たちの短いリストにあります。 まだいくつかの質問/懸念がありますが、来月にはこれに関する動きが見られるはずです。

@mhegazyのコメントがどこから来たのかわからない-TC39提案に関する未解決の質問の数が多すぎて、ここで意味のある作業を行うことができません。 具体的には、 nullとundefinedがどのように相互作用し、どの構文が実際にサポートされているかに関する質問に最初に対処する必要があります。 ステージ2は最低限のものであり、実行時の動作への影響を考慮すると、ステージ3をお勧めします。

これは単にコードが機能しますか？

a == undefined ? expression : undefined

expressionは、ax、a [x]、a（x）、 deleteもここで生成できることを意味します

次に、 a?.b?.[c]?.(d)が生成されます

a == undefined ? (a.b == undefined ? (a.b[c] == undefined ? a.b[c](d) : undefined) : undefined) : undefined

RyanCavanaughのすべてのルールを通過するようです

==演算子が嫌いな場合は、 a === undefined || a === nullの可能性もあります

@ zh99998 ''と0も同等であるため、$ ==を嫌う必要があります。 実行時の動作は(typeof value === 'object' || typeof value === 'function' || typeof value === 'symbol') && value !== nullに対するある種のチェックである必要があるとほとんど主張されていますが、これは現在かなり複雑になっています。

@RyanCavanaughが言ったように、 TC39プロポーザルが少なくともステージ2または3に進むまで、進行する可能性は低いです。

==はnullとundefinedに等しいだけです
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness

Chromeコンソールでテストに合格しました：

'' == undefined
false
0 == undefined
false

@kitsonk undefinedは、nullに強制変換するだけで、その逆も同様です。 他の値が未定義またはnullに強制されることはありません。

あなたは偽りの価値観と混同されているようです。 0と ""は確かに偽物ですが、nullや未定義に強制されることはありません。

==強制を意味します。 null == 0はfalseです。これは、undefined以外はnullを強制できないためです。 undefined == 0についても同じことが言えます。

別の例は

    if(!NaN) console.log("NaN is falsy") // NaN is falsy
    if(false == NaN) console.log("NaN coerces to false")
   else console.log("NaN doesn't coerce to false");// NaN doesn't coerce

あなたは絵を手に入れます。

三項演算子を使用した試みはたくさんありますが、同じプロパティを複数回参照する実装では、予期しない副作用が発生する可能性があります。

幸い、JavaScriptにはIIFEがあるため、アクセサーの結果を関数パラメーターに格納し、必要なだけ参照して、2回以上評価することはできません。 以下の例では、 ?.演算子を含む式の代わりに、複数回呼び出すことができるcoalesceラムダを作成します。

言語の実装者が気にする必要があることの1つは、式の途中での配列と関数の呼び出しです。 コンパイラーはこれらの状況の検出を処理し、それらの式を合体呼び出しの最後に追加するだけでよいと思います。

const coalesce = (x: any, y: string) => x == null ? null : x[y];

const x = {
    y: {
        z: "Hello, World!!!"
    },
    f: () => "Foo!",
    a: ["Array!"]
};

// x?.y?.z
const value1 = coalesce(coalesce(x, 'y'), 'z');

// x?.f()
const value2 = coalesce(x, 'f')()

// x?.a[0]
const value3 = coalesce(x, 'a')[0]

「coalesce」という名前の実際のグローバルは必要ないことに注意してください。 このコードは、任意の式に直接インライン化できます。 しかし、それはそれに名前を付ける膨満感を減らすかもしれません。

演算子に使用される構文や、言語​​の実装者が標準を待ちたいかどうかについてはあまり気にしません。 別のアプローチを披露しようと思っただけです。

これにより、 ??演算子も必要になります。 C＃では、これによりnull式が右側に置き換えられます。

string x = null ?? "Hello";
````

In JavaScript, it is more idiomatic to use `||` to replace "falsey" values with the value on the right. 

```javascript
var x = null || "Hello";

残念ながら、真実性はあまりにも多くのエッジケース（ 0 、 falseなど）をキャプチャします。 null合体（ ?. ）演算子を使用する場合は、 null nessに固有の何かが必要になります。

const x = { y: "" };
const result1 = x?.y || "default";  // I'd expect "default"
const result2 = x?.y ?? "default";  // I'd expect "" 

@ jehugaleahsa 、colesceを使用した例では、前のチェックがnullを返した場合に、関数呼び出しとメンバーアクセスが発生しないようにする方法が必要になります。 x？.f（）の例では、xがnullの場合はfを呼び出さないでください。

@bschlenk同意しないと思います。 null is not a functionのようなメッセージで失敗するはずだと思いますが、それは私次第ではないと思います。

演算子を実装するための可能な方法を詳述するコメントの最近の急増は少し奇妙です。
実装はおそらく解決された問題です。

興味がある場合は、idxライブラリがあります。これは?.演算子の動作によく似ていますが、計画された演算子の多くの詳細も無視されます。 とにかく、コンパイル出力の仕様は、このようなものを実装する方法について疑問に思っている人にとっては興味深いかもしれません。

TSはそのようなものを出力することも、まったく異なるものを出力することもできますが、それが私たちがここで待っていることではないと思います。 ここでは、ES提案がいずれかの方向に移動するまで、TSはオペレーターを取得しないと何度も言われています。

こことここにリストされているのは、まだいくつかの未知数が残っているセマンティクスです。

これを正しく実装し、 ||と? ... : ...が何をするかを理解するために、ここでさらに100個のコメントをする必要はありませんのでご安心ください。 @noppaが指摘したように、ES仕様が完成するのを待っています。

https://github.com/babel/babel/pull/5813（babylon PRに付随）は、Babelのpreset-stage-1にマージされました。 もちろん、仕様はまだステージ1にありますが、これはそれを前進させるのに役立ちます。

たぶん私は間違っていますが、このスレッドでtc39提案への明白なリンクが見当たらなかったので、これは将来の読者のためのものです： https ：//github.com/tc39/proposal-optional-chaining

参考までに、オプションのチェーンは来週TC39で行われますhttps://github.com/tc39/agendas/blob/master/2017/07.md

@jehugaleahsaあなたは正しいと思います。来週、TC39で??を発表します。 ここで提案に従うことができます： https ：//github.com/gisenberg/proposal-nullary-coalescing

オプションの連鎖がTC39でカバーされていたようです...評決は何でしたか？
うまくいけば、Typescriptでこれを前進させるのに十分でした😉

@markwhitfeldメモの要約から：
オプションの連鎖演算子：ステージ1のままで、さまざまなオプションのより明確な定義とフィードバックへの回答とともに後で戻ってきます

ここに完全なメモ： https ：//github.com/rwaldron/tc39-notes/blob/master/es8/2017-07/jul-27.md#13iia -optional-chaining-operator

オペレーターがどのように振る舞うべきかについてはまだ未解決の質問があるので、TypeScriptに追加できる状態にはまだなっていないようです。

それらのメモから、委員会は提示されたオプションがどのように機能するかを知らないように見えます。私は、彼らが議論する前に、彼らが議論することを計画している提案について学ぶために取ったと思いました。 厳密なnullチェックを有効にできるようになるまで、もう少し時間がかかると思います。

私は彼らがオプション2/4（とにかく提案の現在の状態です）で行くことを強く望んでいます。

2014年7月15日-2017年9月4日、まだ何もありません

@frankfvbあなたは明らかに問題を読んでいません。

TypeScriptのこの機能の機能に直接影響を与えるECMAScriptの提案がさらに進展するまで、この時点で実装するのは賢明ではないとコアチームに信じさせる多くの議論がありました。

ECMAScript標準委員会の前回の会議の時点で、提案は、それがどのように実装されるかについていくつかの非常に基本的な質問があるため、ステージ1にとどまっています。 厳格なルールではありませんが、TypeScriptはステージ3の提案のみを実装します。 ステージ2の提案が非常に重要であり、TypeScriptで使用される可能性があると考えられる場合は、ステージ2の提案を実装することがあります。

私はそれについてこれ以上明確な人々がどれほど明確になることができるかわかりません。

前に言ったように、これは私たちの短いリストにあります。 TC39が、演算子のセマンティクスについて何らかのコンセンサスに達するのを待っています。 私たちはそれを消してからユーザーを壊すことを嫌います。

これは、TC39の議論を再ハッシュするためのスレッドではありません

提案を検討したい場合は、適切な場所でコメントしてください。 私も意見がありますが、このスレッドにドロップしても何も起こりません。

私は現在のニーズを満たすシンプルなものを作成しました。 各リンクがプロパティ名であるチェーンでのみ機能するため、配列内の要素へのアクセス（たとえば）はサポートされていません。

TypeScriptでの非常に単純なエルビス演算子の実装

また、lodash / underscoreがある場合は、すでに_.get(Book, 'author.name.firstName')を使用できます。これにより、必要な処理が実行されます。

編集： _.get()メソッドのタイプの問題のため、これは明らかに悪いアドバイスです。 以下のコメントを参照してください

@tolgaek 、 _.getはタイピングが悪いですが、このより良いタイピング（作成者のためにまだマージされていません）でも、typescriptは、オブジェクトの深さが1の場合にのみ、結果のタイプを確実に推測できます。それ以外の場合はすべてanyです。

一方、エルビス演算子を使用すると、typescriptは任意の深さのオブジェクトの結果のタイプを推測できる可能性があります。これが、Imがエルビス演算子を楽しみにしている理由です。

なるほど、タイピングの問題があるとは知りませんでした。 ありがとう@BjornMelgaard

@mhegazyこの機能を最初に実装して、実験的な機能としてマークすることはできませんか？ 実験的な機能に仕様が変更されていれば、問題はないはずだと思います。

エルビスはこれほど長く待っても面白がっていません。

Babel7に上陸しました。 Typescript、実行速度が遅いです。誰かがこれを起こしてください。
:)

@ gs-akhan Babelプラグインは、数か月前の古いバージョンの提案を実装しています。 それ以来、提案に変更が加えられており（演算子の解析方法の大幅な変更を含む）、機能がステージ2（ステージ3は言うまでもなく）に到達する前にさらに変更が加えられる可能性が高いため、現在のバベルで記述されたコードはすべて実際の機能がリリースされると、プラグインが破損する可能性があります。 Babelは、提案された機能が安定する前に意図的に実装し、仕様の作成者やその他の関係者が提案された機能を試すことができるようにします。 Babelが機能を実装したからといって、将来的に重大な変更を必要としない方法で実装できるとは限りません。

@alangpierceそれは理にかなっています。 ありがとう

これは本当に本当に素晴らしいオペレーターだと思いますが、ルールが解決される前に利用できるようにすることはフットガンであり、それを行うつもりはありません。 オペレーターの実行時の動作はまだ流動的です。 今日コードを書くと、すぐにはわからない方法で明日は機能しなくなる可能性があります。まれなクラッシュやデータの破損など、誰が知っているでしょうか。 少しの忍耐が今あなたに数ヶ月先の多くの苦痛を救うでしょう。

仕様の準備ができるまで、このチケットをロックする（閉じない）必要があると考え始めます。

スペックはいつ準備できますか？

@oliverjanik現在のドラフト仕様はここにあります。 次のTC39会議（9 / 26-9 / 28）で提案をステージ2に進めるための議題項目があります。 その際、これらのスライドを紹介します。 早期に確認してフィードバックを提供したい方は、提案リポジトリに問題を提出してください。

この問題を支持してくれてありがとう@gisenberg ！ 混乱を避けるために、TC39ミーティングで使用できるオペレーターの周りのオプションを明確にするために、要約スライドデッキをまとめることを考えていましたが、すでにこれを行っています。 お見事！
TC39の会話（およびスライドデッキ）に役立つ可能性のあるもう1つのことは、他の言語での演算子のセマンティクスと構文を調べることです。 他の言語は必ずしもJavascriptでの動作を指示する必要はありませんが、混乱を避けるために、演算子を他の言語と同じように保つと便利です。
来週頑張ってください!!!

もう一度話題から外れて申し訳ありませんが、ここの何人かの人々は、Flowで_.getのような安全なゲッター関数のためにいくらか機能する型定義を追加できるようになったことを興味深いと思うかもしれません。

例： flowtype.org/try

これまでで最も美しいコードではなく、nullとundefinedを正しく区別していませんが、それ以外は非常にうまく機能しているようです。

TSに同じことをするために欠けているのは、 $NonMaybeTypeのようなものだけです。
もちろん、この演算子が不要になるわけではありません。それはすばらしいと思いました。

これは、ブラケット、ドット、呼び出しアクセス、およびセマンティック動作（ undefined / nullの右側の式の副作用に関する予測可能性）に関する構文の一貫性に関する懸念のため、最新のTC39会議でステージ2に到達しませんでした。 x.bがnumber $の場合は$ x.?b() $＃$）

（腐った果物を投げるためにこのコメントに投票🎉）

知らせてくれてありがとう。 なんて残念だ。 スコープを狭める必要があるかもしれません。そうすれば、よりシンプルになりますが、それでも便利ですか？

スコープを狭める必要があるかもしれません。そうすれば、よりシンプルになりますが、それでも便利ですか？

これはTC39が直面している課題であり、これは厄介ですが、人々がこれを経験してくれてうれしいことを認めなければなりません。 彼らがかなり複雑なレベルの構文を導入するのは本当に難しいです、そして実際、この場合、言語の弱い型付けは実際に対処しなければならないかなりの量のエッジケースを引き起こしています、またはあなたはそうではないコードを手に入れます💥誰にとっても良くありません。 このような演算子を導入すれば、実際にその範囲を狭めることができるとは思いません。 実装者がケースの90％をカバーする方が簡単ですが、残りの10％では¯\_(ツ)_/¯が有効なコードではないと思います。

みんな、3年以上後、私は委員会に「あなたをファック」と言って、TypeScriptに慣用的なものは何でも、私たち自身のやり方でそれをする時が来たと思います。 この機能は、とにかく静的型付けなしでは正しく機能しません。

TC39の提案と明示的に互換性のない構文を使用してTypeScriptの実装を作成します。 ESがsafe-nav演算子を取得すると、TypeScriptには2つのオプションがあります。1つはESと互換性のあるくだらないセマンティクスを持ち、もう1つは型システムに関連付けられています。 これは、TS safe-nav演算子をどの「タイプ」でも使用できないことを意味し、それで問題ありません。

@notsnotso TypescriptはJSを壊すことは想定されていません。それが、Coffeescriptの目的です。

たぶん良い解決策は次のとおりです。

• 非常に簡単に実装しますか？ 実験的な機能（デコレータなど）として、警告付きのせっかちな開発者向けの演算子-将来的にコードが破損します
• 標準が作成されるまでさらに3年間待ち、非実験的な機能として実装します。 チュートリアルを書いてください、何が壊れている可能性があります。 静的型付けを使用しても、新しい演算子の実装でコードをコンパイルするときに警告を書き込むことができます。
  「TypeScriptに慣用的なものは何でも、私たち自身のやり方でやってください」はそうではありません。なぜなら、3年後には人々が問題に直面し、tselvisがjsと同じように機能しないからです。

正直言って、これがうまくいかなかったのは驚きではありません。 私のオリジナルでは
投稿では、インデックス作成や関数呼び出しなどに関するあいまいさを指摘しました。
正直なところ、 ?.について考えれば考えるほど、そうではないように感じます。
undefinedがあるため、JavaScriptに属します。

私はむしろこの問題を解決したもっと汎用的なユーティリティが欲しいです
もっと。 私が持っていた1つの考えは、インラインtry/catchのようなものでした
式（ let x = try a.b.c else 0 ）と演算子
「falsey」（たとえば、x || 1）ではなく「nully」（たとえば、x ?? 1）をチェックしました。
したがって、次のように組み合わせます： try a.b.c ?? 0 else 0 。 それは言葉です、はい、
しかし、基本的には次のように述べています。abcを評価してみて、結果がnullか
undefined 、0を返します。aまたはbがundefinedであり、例外がスローされた場合、
それをキャッチし、0を返します。

別の方法は、 else句をオプションにし、デフォルトで
undefined 。 次に、式を次のように記述できます： let x= (try a.b.c) ?? 0 。 これはかなりコンパクトで、あいまいさを回避し、より多くの機能を提供します
他の問題を解決できる汎用ソリューション。

代わりにこれを推進すべきだと言っているのではありません。 私が言っているのはそこにあるすべてです
?.の代替手段であり、私たちが
JavaScript言語によく合うものを見つけてください。

2017年10月5日木曜日午前7時51分、Dmitry [email protected]
書きました：

@notsnotso TypescriptはJSを壊すことは想定されていません、それが
Coffeescriptはのためのものです。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/Microsoft/TypeScript/issues/16#issuecomment-334441781 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/ABTgPilbZfuKc2egdBrYfdTHHeDl3F6Sks5spMLLgaJpZM4CNapf
。

@zlumer素敵なジョーク。 そうは言っても、TS固有の機能はJavascriptを壊すことはありません。

@jehugaleahsa私はあなたの提案が好きです、そしてそれは他の言語で見つけられます。 TSでは問題なく動作すると思います。

ECMAScriptが演算子を受け入れるまで待つ必要があることを私は本当に理解していないと言います。 TypeScriptは、クラス、モジュール、ラムダをECMAScriptに導入するずっと前に追加しました。 実際、TypeScriptの目標の1つは、実験的なJS機能を試験的に導入することでした。 独自の実装を提供するTypeScriptは、委員会でのこれらの議論に情報を提供するのに役立つことは間違いありません。

委員会が最終的に別の方向に進む前に、皆さんは画期的な変更を喜んで受けてきました。なぜこの機能がそれほど異なるのか、私にはよくわかりません。

async / awaitも初期の段階でTypeScriptに導入されました。

そうは言っても、TS固有の機能はJavascriptを壊すことはありません。

「TS固有の機能」のようなものはありません。詳細については、 TypeScriptの設計目標を確認してください。

_{TypeScriptは、ESが明るい道を進む前に到着します。既存のものがいくつかある可能性がありますが、それらは互換性のために保持されています。}

TypeScriptは、クラス、モジュール、ラムダをECMAScriptに導入するずっと前に追加しました。

そして、特にモジュールは、混乱を終わらせることのない大きな大失敗です。 これは、TypeScriptチームが_間違い_の例として繰り返し使用し、あまりにも早く銃をジャンプさせた例です。 現在、私有地も迫っています。これも、過去5年間privateに感謝していますが、混乱を招くことはありません。

繰り返しになりますが、デコレータはフラグの下で利用可能ですが、デコレータが実際にステージ3に到達しているため、TypeScriptの再実装とコードの破損が必要になります。 そのため、これらのことは起こりそうにありません。

async / awaitも初期の段階でTypeScriptに導入されました。

ECMAScriptプロポーザルがステージ3に到達すると。

誰も不正行為をしていませんが、この会話がサークル内（フラグがあった場合はどうなりますか？はい、フラグを認識しています）またはトピック外（TSがJSでなくなった場合はどうなりますか？いいえ5年後は変更されません）以外の場所に行けない場合そのことについての私たちの心）、私たちはそれを持っている必要はありません。 ES委員会がそのセマンティクスをロックダウンしたときにこれを正確に実装することを約3年前から言ってきました。

繰り返しになりますが、プロポーザルリポジトリはhttps://github.com/tc39/proposal-optional-chainingであり、そこで進行状況を追跡できます。 次回のTC39ミーティングでも提案の可能性を高めるために、オフラインで作業します。これも本当にやりたいからです。

更新：今日の午後、TC39でステージ2に到達しました!!!

オプションの連鎖はステージ3です

お祝いの目的でのみこれを簡単にロック解除します

やったー！

スパムしないでください...

自分の気持ちを表現した絵文字を送ることができます

スパムしないでください...

自分の気持ちを表現した絵文字を送ることができます

さらに、このように絵文字の数が増えるのを見るのも楽しいです。 問題のコメントがこれほど急速に人気を博しているのを見たことがありません。

リアルタイムアップデートの小さなビデオを録画しましたhttps://youtu.be/JLBrgPjeGhc

誰かが私をこのことから退会させることができますか？

@DanielRosenwasser冗談を言っていない場合、または登録を解除したいが方法がわからない人のために、右側のサイドバーでこのボタンを探しています。

言うまでもなく、電子メールには次のリンクがあります。

_{それは冗談でした、私は提案に取り組んでいます。}

この問題のロックを解除した後の@RyanCavanaugh ：

これがついに着陸するのを見て本当に興奮しています！ 🎈🎉

一致するVSCodeクイックフィックスを待つことはできません😆

私は@@ RyanCavanaughに行きます。なぜなら、彼はおそらくこのスレッドの購読を解除されており、失礼になりたいからです。 （そして@DanielRosenwasserは良い尺度です）

@kitsonkお尻にならないでください。 人々は自由に退会でき、嫌がらせを受けることはありません。

@kitsonk 、なぜRyanCavanaughまたはDanielRosenwasserがこのスレッドの購読を解除されるのですか？ ライアンはこの問題のロックを解除し、ダニエルはあなたの上の3つのコメントに答えました。

それらが購読解除されたとしても、それらをスパムすることによって通知の疲労を引き起こす必要はありません。

どうやらGitHubは皮肉なユーモアのためのひどい場所です、ジー...

この新しい言語機能の厄介な詳細を理解してくれたTC39のチャンピオンに感謝します！

@kitsonkは、私がそうだったように、冗談を言っていたと思います。 私たちは興奮の周りで少しばかげていますが、これはCoCに従って物事を礼儀正しく保つための穏やかなリマインダーです。

@DanielRosenwasser
これを試してみる必要がありますか？ または、 @ rbucktonにはさらに別のブランチがあります🙋🏻‍♂️

わかりました、わかりましたhttps://github.com/microsoft/TypeScript/commits/optionalChainingStage1🤦🏻‍♂️

残念ながら、それはかなり時代遅れです。

この号は5年前に開かれたことに気づきました。 ：びっくり：

@rbuckton

残念ながら、それはかなり時代遅れです。

これを試してみませんか？

申し訳ありませんが@ jhpratt @ MatthiasKunnenGitHubで同じコンテキストを共有しているわけではないことを忘れました。 私は長い間この辺りで跳ね回っていて、ライアンとダニエルIRLと一緒に時間を過ごし、最近のイベントに簡単に参加して、私の誤解された内輪ネタを引き起こしました。 謝罪。

しかし、この問題全体は、TypeScriptの設計原理の興味深い考古学を示しています。 Ryanは、TypeScriptがECMAScriptで真剣に検討する前の構文を実際に検討していたときに、それを提起しました。 TypeScriptが内部的に、言語に深刻な影響を及ぼしているES2015構文を予測するいくつかのレッスンを学んでいたのはその頃でした。 チームは、TC39ステージ3の提案が出るまで、参加を検討しないことにしました。

@RyanCavanaughはそれに対処でき、彼は提案で起こったことに近づいていることを私は知っていますが、2014年にチームが実装したものが現在のステージ3の提案と100％互換性があるとは考えられなかったと思います。 したがって、これは確かにお祝いですが、提案の動作と完全に一致しない安全なナビゲーション演算子を使用したTypeScriptコードが5年間ないことにも感謝します。

🙏

これは、 Waiting for TC39ラベルを削除する瞬間ですか？ 🤔

これは、 Waiting for TC39ラベルを削除する瞬間ですか？ 🤔

そしてship-itを追加します

すごい

ついに。 文字通り、オプションのチェーンについて質問していました。それはいつステージ3になるのか、そしてバム！ それを押し進めるために働いていたすべての人に感謝します！

このスレッドをミュートする方法は？ :)

@opnksynスパムの興奮を気にしない場合は、この問題が解決されたときに通知を受け取る機能があります。 これにより、作成したばかりのような通知にすべてのコメントが表示されなくなります😄

すでに定義されている放出ソリューションはありますか？
このようなものは興味深いかもしれません：

function __chain<T extends object, U>(value: T|null|undefined, callback: (value: T) => U): U|undefined {
    if (value !== null && value !== undefined) {
        return callback(value);
    }

    return undefined;
}

type Foo = { x?: { y?: { z?: () => number } } }

const foo: Foo|null = { }

// foo?.x?.y?.z?()
const value = __chain(foo, _a => __chain(_a.x, _b => __chain(_b.y, _c => __chain(_c.z, _d => _d()))));

不要な関数スコープの作成を回避するため、Babelが行うことを好みます。

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
    : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
    : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
    : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
    : _foo$x$y$z.call(_foo$x$y);

不要な関数スコープの作成を回避するため、Babelが行うことを好みます。

var _foo, _foo$x, _foo$x$y, _foo$x$y$z;

// foo?.x?.y?.z?.()
(_foo = foo) === null || _foo === void 0 ? void 0
  : (_foo$x = _foo.x) === null || _foo$x === void 0 ? void 0
  : (_foo$x$y = _foo$x.y) === null || _foo$x$y === void 0 ? void 0
  : (_foo$x$y$z = _foo$x$y.z) === null || _foo$x$y$z === void 0 ? void 0
  : _foo$x$y$z.call(_foo$x$y);

同意します、@ ExE-Boss。 不要な関数スコープを作成しないことが理想的だと思います（コンパイルされたコードが少し醜い場合でも）

コンパイルされたコードについて話しているとき、パフォーマンスとES仕様への準拠は、読みやすさよりも確実に勝つはずです。

Babelによってコンパイルされたコードがnullとvoid 0の両方と比較して、単純な== nullではなくトリプルイコールを使用する理由はありますか？

Babelによってコンパイルされたコードがnullとvoid 0の両方と比較して、単純な== nullではなくトリプルイコールを使用する理由はありますか？

@proteria__Babel__のオプションのチェーンコードをざっと見てみました。 looseオプションを渡して、それを真の値に設定すると、厳密な等価性チェックが生成されないようです。

これは、 document.all （または衒学的には[[IsHTMLDDA]]内部スロット）が原因です。これは、下位互換性のために言語で特別な扱いを受ける癖です。

document.all == null // true
document.all === null || document.all === undefined // false

オプションの連鎖提案で

document.all?.foo === document.all.foo

ただし、 document.all == null ? void 0 : document.all.fooは誤ってvoid 0を返します。 ルーズモードでは、ほとんどの人がとにかくdocument.allを処理する必要がないため、この仕様の詳細は単純化/パフォーマンス/生成されたコードサイズのために却下されます。

確かにdocument.allの場合は特別かもしれませんか？ オブジェクトとプロパティをチェックするために数行を追加するだけで、余分なコードはそれほど必要ありません。

document.allを変数に割り当てることができ、それが使用されている場所を追跡するには型システムが必要です。そのため、Babelはデフォルトで次のように出力します。

(_prop = prop) === null || _prop === void 0 ? void 0 : _prop./* do stuff */;

私はそれを知っています。 Babelには型システムがありませんが、TypeScriptにはあります。 思ったほど簡単ではないかもしれませんが、使用状況を追跡できる特定の状況向けのコードがすでにあると思います。

実際には、 document.all変数を追跡するための型システムは必要ありません。これは、特別な動作が実際にはdocument.all HTMLAllCollectionにあるためです。

したがって、 instanceof HTMLAllCollectionのチェックを実行できるはずです。そうすれば、金色になります。

ええ、でも... === null || === void 0ができるのに、なぜinstanceofをするのですか？ 確かにそれはもっと簡単です。

確かに-私はあなたがdocument.allを追跡するために型システムを必要としないことを指摘していました:)

個人的には、それを壊して誰が文句を言うのかを知りたくなりますが、それは仕様に含まれているので、それに固執するのが最も簡単です。

@noppaコンパイル時に実行できます。 foo instanceof HTMLAllCollectionがtrueの場合、 foo === null || foo === void 0を放出します。それ以外の場合は、 foo == nullを安全に放出できます。

@ G-Rath好むと好まざるとにかかわらず、廃止されたからといって、機能しないという意味ではありません。 TypeScriptはJavaScriptとの互換性を維持する必要があります。

@jhprattしかし、それは現在、 TypeScript Design Non‑Goalsに反しています。

また、 HTMLAllCollectionを割り当てることができるものについては、 foo === null || foo === void 0を実行する必要があります。 anyまたはobjectなので、それだけの価値はないと思います。

あなたは非目標について言及していると思います（5）

プログラムに実行時型情報を追加または依存するか、型システムの結果に基づいて異なるコードを発行します。 代わりに、実行時のメタデータを必要としないプログラミングパターンを奨励してください。

これは確かにタイプに基づいて異なるコードを出力することに同意しますが、それはコードサイズを減らすためだけです。 ご指摘のとおり、 HTMLAllCollectionをチェックするほど簡単ではありません。

公平を期すために、TSは型情報を使用する潜在的なミニファイアを拒否しました。これは（一種の）関連性があります。 == nullを発行する主な理由は、型情報に基づいてコードサイズを縮小することです。

これが実装されていない場合は、langチームがBabelの「緩い」オプションと同様のオプションをtsconfigに追加すると便利です。

すばやく確認した後、 terser foo === null || foo === undefinedをfoo == nullに自動的に変換します。これは、このエッジケースのために安全ではありません。

これが実装されていない場合は、langチームがBabelの「loose」オプションと同様のオプションをtsconfigに追加すると便利です。

関連して、私たちの多くは、ビルドツールやモバイルアプリケーションにTypeScriptを使用していますが、ブラウザーの制約について心配する必要はありません。

実際、TSとBabelの両方を一緒に使用しているため、これらのオプションの1つは、オペレーターをBabel /基になるランタイムにパススルーすることです。

@fbartho

実際、TSとBabelの両方を一緒に使用しているため、これらのオプションの1つは、オペレーターをBabel /基になるランタイムにパススルーすることです。

このコメントがわかりません。 演算子をBabelにパススルーするための追加のオプションは必要ありません。 TypeScriptをBabel用に設定している場合は、すでにnoEmit: trueがあり、これはすでに_everything_をBabelに渡します。

@Zarel BabelのTypeScript実装には、名前空間やconst列挙型など、コードベースがすでに依存していたいくつかの機能がありません。 エミットを有効にしてTSCを使用し、2番目の変換としてBabelを適用しています。 （名前空間の削除に取り組んでいますが、不一致の機能をすべて削除できるかどうかは不明です）

このスレッドにアクセスする人は、ステージ3の初期の発表から始めて、そこから始まるコメントを読む必要があります（GitHubが、すべてをロードする簡単な方法がなく、大量のユーザーコンテンツを非表示にしたことを非難します）

優れた機能-「オプションの連鎖」/「安全なナビゲーション」。 特にTypeScriptのstrict-modeで。 これがまもなく実装されると聞いて素晴らしいです。 ❤️

これは私をここに連れてきました、そして私はそれがサポートされることを願っています。 単なるユースケース：

TypeScript3.7で期待されています。

document.querySelector('html')?.setAttribute('lang', 'en');

VS

現在TypeScript3.5にあります。

const htmlElement = document.querySelector('html');
if (htmlElement) {
  htmlElement.setAttribute('lang', 'en');
}

これはエラーなしで機能しますか？ それとも、これはまだTypeError: Cannot read property 'setAttribute' of null.ですか？ ? op。 null /未定義の後にチェーンをキャンセルする必要があります。

class Test {
  it() {
    console.log('One');
    document.querySelector('html')?.setAttribute('lang', 'en');
    console.log('Two');
  }
}
new Test().it();

私は次のことを期待しています：
html要素が存在しない場合（null）。 コンソールはOneとTwoをログに記録する必要があり、 setAttributeメソッドは呼び出されません。 （エラーなし）。
私はそれを正しく理解しましたか？

@domske参考までに、これは厳密にはTS機能ではありません。 これはJSの機能です。

TC39の提案によると、構文は次のようになります。

document.querySelector('html')?.setAttribute?.('lang', 'en');

議論は再び循環し始めたので、私たちはロックされた状態に戻ります。

100コメント以上の長いGitHubスレッドにコメントを残して、以前のすべてのコメントを最初に読むことを本当に約束したいと思っている人には、本当にお願いします。 おそらくあなたの質問とその答えはそこにあります！