Typescript: Vorschlag: "safe navigation operator", dh x?.y

Erstellt am 15. Juli 2014  ┬Ě  205Kommentare  ┬Ě  Quelle: microsoft/TypeScript

Aktueller Status

  • Der TC39-Vorschlag befindet sich jetzt in Phase 3 (­čÄë­čÄë­čÄë­čÄë­čÄë)
  • Die Umsetzung ist im Gange
  • Sie k├Ânnen diese Funktion in TypeScript 3.7 erwarten
  • Wir werden hier aktualisieren, wenn es in einem n├Ąchtlichen Build verf├╝gbar ist
  • Warten auf Optional Call, bis seine Semantik im Komitee gekl├Ąrt ist

Offene Fragen

  • Welchen Sonderfall sollte document.all erhalten, wenn ├╝berhaupt?

C# und andere Sprachen haben Syntaxzucker f├╝r den Zugriff auf Eigenschaftsketten, bei denen null (oder in unserem Fall undefined ) an jedem Punkt in der Objekthierarchie auftreten k├Ânnen.

var x = { y: { z: null, q: undefined } };
console.log(x?.y?.z?.foo); // Should print 'null'
console.log(x?.baz); // Still an error
console.log(x.y.q?.bar); // Should print 'undefined'

Ben├Âtigen Sie einen Vorschlag, was genau wir kodieren sollten, unter Ber├╝cksichtigung der Nebenwirkungen von Zugriffsmitteln.


Bearbeiten von @DanielRosenwasser 27. Februar 2018: Dieser Vorschlag wird auch als "Null-Propagation"-Operator bezeichnet.

Committed ES Next Suggestion Update Docs on Next Release

Hilfreichster Kommentar

Optionale Verkettung ist Stufe 3

Diesen nur zur Feier kurz aufsperren

Alle 205 Kommentare

Im ersten Beispiel k├Ânnten wir es also wie folgt ausgeben:

x && xy && xyz && xyzfoo

Aber dann m├╝ssten wir irgendwie daf├╝r sorgen, dass x, y, z und foo jeweils h├Âchstens einmal ausgewertet werden.

Sie k├Ânnen in vielen F├Ąllen auch nicht wirklich && machen, weil Wahrhaftigkeit f├╝r Primitiven zu einem kleinen Problem wird.

Zum Beispiel:

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

gibt "" .

Sie m├╝ssen also einige explizite Vergleiche mit null durchf├╝hren, wobei == f├╝r den allgemeinen Fall verwendet wird, es sei denn, wir nutzen das Typsystem (was ziemlich cool w├Ąre, wenn wir das tun w├╝rden).

Wir k├Ânnten m├Âglicherweise eine monadische Bindungsfunktion ausgeben (nicht h├╝bsch f├╝r die JS-Ausgabe) oder eine Transformation f├╝r tern├Ąre Operatoren verwenden (n├Ąher an einem typischen JS-├äquivalent). Ich bin eindeutig etwas voreingenommen gegen├╝ber letzterem.

:+1:

Idealerweise sollte ES7 (oder ES8 oder ES9 oder ...) dies zuerst implementieren, da es wahrscheinlich einige Meinungsverschiedenheiten ├╝ber die genaue Semantik dar├╝ber geben w├╝rde, ob 0 / "" tats├Ąchlich verwendet werden soll oder nicht.

:+1: Ich w├╝rde gerne sehen, dass TypeScript dies zuerst bekommt, ohne auf ESxx warten zu m├╝ssen.

Die Tatsache, dass einfache und wahnsinnig n├╝tzliche Nullsicherheitsoperatoren wie "?." und "?:" SIND NICHT in der ES6-Spezifikation bedeutet, dass die Leute, die die ES6-Spezifikation zusammenstellen, ihre K├Âpfe vor Scham h├Ąngen lassen sollten. Dies ist eine so einfache und offensichtliche Sache, dass es ehrlich gesagt verr├╝ckt w├Ąre, es nicht zu integrieren. Es gibt einen Grund, warum die meisten modernen Sprachen diese unterst├╝tzen: Sie sind unverzichtbar.

Mir ist klar, dass dies eine Abweichung von der aktuellen Spezifikation w├Ąre (da die aktuelle Spezifikation so kurzsichtig ist, dies wegzulassen). Aber es ist so l├Ącherlich n├╝tzlich, dass ich denke, dass diese eine Abweichung gerechtfertigt w├Ąre. Die ├╝berwiegende (GROSSE) Mehrheit der TS-Entwickler w├Ąre von geringf├╝gigen ├änderungen an der Implementierung nicht betroffen, falls oder wenn diese schlie├člich zu einer ES-Spezifikation hinzugef├╝gt werden. Die enormen Vorteile, die dies bieten w├╝rde, sind die potenziellen zuk├╝nftigen Auswirkungen f├╝r einen winzigen Bruchteil der Entwickler wert. Und angesichts des l├Ącherlich langsamen ES-Spezifikationsprozesses w├╝rde dies (mindestens) mehrere Jahre lang ├╝berhaupt keine Rolle spielen.

Ich stimme brain428 vollkommen zu

@brian428 Das Problem hier ist, dass dieser Operator m├Âglicherweise in ES7 implementiert ist. Wenn also Typoskript mit einer Spezifikation verwendet wird, die sich von der endg├╝ltigen ES7-Spezifikation unterscheidet, wird niemand gl├╝cklich sein.

Das Problem dabei ist, dass dieser Operator m├Âglicherweise in ES7 implementiert ist. Wenn also Typoskript mit einer Spezifikation verwendet wird, die sich von der endg├╝ltigen ES7-Spezifikation unterscheidet, wird niemand gl├╝cklich sein.

Ich denke, es ist ein positiverer Ansatz f├╝r TypeScript, Funktionen zu implementieren, die es m├Âglicherweise _ (oder auch nicht) in eine zuk├╝nftige ES-Version schaffen, da dies eine n├╝tzliche Testumgebung f├╝r die Beeinflussung der ES-Richtung sein wird.

Hier ist ein Beispiel f├╝r eine ES-Diskussion, die von TypeScript beeinflusst wird :

Die Option TypeScript... zum Deklarieren und Initialisieren ├╝ber ein privates Pr├Ąfix f├╝r einen der Parameter des Konstruktors w├Ąre f├╝r viele Entwickler hilfreich

Dar├╝ber hinaus ist es sicherlich m├Âglich, dass ES eine Funktion ├╝bernimmt, die bereits in TypeScript vorhanden ist, jedoch mit einer anderen Semantik (z. B. in Bezug auf die Funktionsweise von Modulen).

Es ist sicherlich m├Âglich, dass ES eine Funktion ├╝bernimmt, die bereits in TypeScript vorhanden ist, jedoch mit einer anderen Semantik

Ich sollte anmerken, dass wir dies im Gro├čen und Ganzen als ein Worst-Case-Szenario betrachten. Wir wollten wirklich, dass Module in ES6 fertiggestellt werden, bevor wir TypeScript 1.0 deklarieren, aber die Zeitplanverz├Âgerungen des Komitees verhinderten dies. Dies ist etwas zu vermeiden, nicht zu wiederholen. Wir w├╝rden wirklich gerne Funktionen treffen, die entweder eine Chance von ~0┬á% haben, es in ES7+ zu schaffen (z. B. Typanmerkungen), oder eine Chance von ~100┬á% haben, es in ES7+ zu schaffen (z. B. wo dicker Pfeil zwei war vor Jahren). Neue Betreiber fallen wahrscheinlich in die unangenehme Mitte.

K├Ânnte ein Compiler-Flag im schlimmsten Fall, wenn ES7 sich unterscheidet, die Legacy-TS-Implementierung unterst├╝tzen und somit eine Nachfrist bieten? Dies in Verbindung mit einer klaren Migrationsdokumentation sollte Entwicklern einen einfachen Weg zu jedem neuen Standard bieten.

Letztendlich ist die Verwendung einer solchen Funktion ÔÇô obwohl wahnsinnig n├╝tzlich ÔÇô f├╝r Entwickler nicht unbedingt erforderlich. TS sollte potenzielle zuk├╝nftige Auswirkungen seiner Nutzung vom ersten Tag an deutlich machen. M├Âgen Sie die Idee eines potenziell verwalteten Refactoring nicht, verwenden Sie es nicht. Vielleicht ein Opt-in-Compiler-Flag, um diese Nachricht zu erzwingen?

TS sollte nicht wild darauf sein, ES beeinflussen zu wollen, aber in kleinen Einzelf├Ąllen wie diesem w├Ąre es schade, wenn TS komplett davor zur├╝ckschrecken w├╝rde.

Vielleicht k├Ânnten wir daf├╝r einen Strohmannvorschlag zusammenstellen und dann eine Referenzimplementierung hinter einem --harmony-Flag (oder so ├Ąhnlich) haben. Auf diese Weise k├Ânnen wir die ES7-Entwicklung dieser Funktion vorantreiben.

Um Seiteneffekte durch wiederholtes Nachschlagen zu vermeiden, muss der Compiler entweder tempor├Ąre Variablen ausgeben:

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

oder verwenden Sie eine memoisierende Membran, die auf Proxy basiert.

Aus kategorialer Sicht ist dies nur die Vielleicht-Monade, die auf die Eigenschaftssuche angewendet wird, also ist es ein sehr nat├╝rliches Merkmal f├╝r eine Sprache, in der alle Eigenschaftssuchen undefiniert zur├╝ckgeben k├Ânnen. Ich w├Ąre ├╝berrascht, wenn ES7 eine andere Semantik als die im obigen Code beschriebene annehmen w├╝rde.

Die Codeplex-Ausgabe hatte eine ganze Reihe von Stimmen (61)

Ich brauche das wirklich dringend, um die Schmerzen bei der Verwendung von atom f├╝r Atomtyposkript zu lindern.

Es ist im Coffescript-Code sehr idiomatisch (obwohl ich m├Âchte, dass es nicht so beliebt ist, da Determinismus besser ist als ein fummeliges ? ). ├ľffnen Sie eine beliebige Coffescript-Datei, insbesondere eine, die mit dem DOM direkt wie ein Leerzeichen funktioniert (wobei Funktionen ausgef├╝hrt werden k├Ânnen, nachdem die Ansicht zerst├Ârt oder bevor die Ansicht angeh├Ąngt wurde), und Sie werden eine Unmenge ? Verwendungen finden. zB hat diese Datei 16 https://github.com/atom-community/autocomplete-plus/blob/f17659ad4fecbd69855dfaf00c11856572ad26e7/lib/suggestion-list-element.coffee

Auch hier gef├Ąllt es mir nicht, dass ich das brauche, aber es ist der Zustand von JavaScript, und ich h├Ątte lieber ? als eine Million if( && fest ) { then }

Aber ich brauche es wirklich, um meinen Code lesbar zu halten. Es ist auch sehr ├╝blich, dies zu _brauchen_, wenn Sie darauf warten, dass ein XHR seine Digest-Schleife abschlie├čt und eckig durchl├Ąuft.

Okay, jetzt habe ich den Thread gelesen und sehe, warum wir warten. Ich verstehe _seufz_.

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

coffeescript f├╝hrt einige Optimierungen durch, z. B. speichert Zwischenzugriffsergebnisse :

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

(Ich bin der festen ├ťberzeugung, dass die undefined -Pr├╝fung f├╝r Typoskript unn├Âtig ist: da wir eine var -Init-Typpr├╝fung durch Typoskript haben sollten.)

+1

In den heutigen Nachrichten erh├Ąlt Dart offizielle Unterst├╝tzung daf├╝r: https://github.com/gbracha/nullAwareOperators/blob/master/proposal.md

Sehr wichtige Funktion.

M├Âglicherweise eine ausgefallene Idee, aber das Codegen f├╝r dieses Feature k├Ânnte sehr einfach ohne Nebenwirkungen durchgef├╝hrt werden, wenn alle entscheiden w├╝rden, dass es in Ordnung w├Ąre, das Feature mit verschl├╝sseltem Eigenschaftszugriff zu handhaben:

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

K├Ânnte kompilieren

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

Eine __chain Funktion m├╝sste ├Ąhnlich wie __extends werden. Die Funktion __chain k├Ânnte einfach das Array arguments durchlaufen und null zur├╝ckgeben, wenn das n├Ąchste Mitglied nicht instanceof Object ist oder den Mitgliedsnamen nicht enth├Ąlt. Funktionsaufrufe k├Ânnten behandelt werden, indem ein Array als Parameter ├╝bergeben wird (und .apply() unter der Decke verwendet wird), also ...

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

K├Ânnte kompilieren

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

Dies w├╝rde auch das generierte JS selbst f├╝r lange Ketten einigerma├čen idiomatisch halten.

Muss nat├╝rlich verfeinert werden ... aber vielleicht ist hier etwas dabei?

Wenn aaa?.bbb?.ccc? den Wert von a.b.c #$ zur├╝ckgibt, wenn alle Requisiten existieren und es zuf├Ąllig eine Funktion ist, dann geht das nicht

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

kompilieren zu

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

?

@metaweta : Ihre L├Âsung sucht nur nach void 0 ... macht das nicht den Zweck der Funktion zunichte?

Was ist damit:

var result = one?.two?.three;

Erzeugt:

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

Ich bin mir ziemlich sicher, dass dies alle F├Ąlle behandelt. Funktionsaufrufe w├╝rden wahrscheinlich einen instanceof Function -Check ben├Âtigen.

(Kleiner Nachteil hier, dass unerwartete lokale Variablen ausgegeben werden ... k├Ânnte vielleicht in ein IIFE gepackt werden)

@kevinb7 : Was passiert, wenn ccc keine Funktion ist? Mit dem von Ihnen beschriebenen Code m├╝sste __chain immer eine g├╝ltige Funktion zur├╝ckgeben, oder es w├╝rde ein TypeError ausgegeben werden.

@Back-io Wenn eine Eigenschaft fehlt, gibt eine Suche undefiniert === void 0 zur├╝ck. Ihre L├Âsung schl├Ągt fehl, um Eigenschaften von falschen Werten wie leere Zeichenfolge und Null nachzuschlagen.

@metaweta : Nein, tut es nicht: http://jsfiddle.net/25LppbL6/

Au├čerdem k├Ânnte ich mir vorstellen, dass das TS-Team nicht gerade verr├╝ckt danach ist, lockere Gleichheit zu verwenden, da die Linters einiger Leute davor warnen.

@Back-io Ja, das tut es: http://jsfiddle.net/25LppbL6/2/

@Back-io In Bezug auf null bin ich mir nicht sicher, was die beabsichtigte Semantik von a?.b ist. Wenn es "Wenn die Eigenschaft b definiert ist, dann verwende sie" lautet, ist mein Code fast korrekt. Die einzige M├Âglichkeit, null zu erhalten, besteht darin, dass es als null zugewiesen wird, da die Suche nach nicht vorhandenen Eigenschaften undefiniert zur├╝ckgibt. Der Fall, in dem die Eigenschaft vorhanden ist, aber auf undefiniert gesetzt ist, wird nicht erfasst. Um ganz korrekt zu sein, w├╝rde es mit Object.hasOwnProperty() pr├╝fen, anstatt mit void 0 === undefined zu vergleichen.

Wenn die Semantik lautet: "Wenn die Eigenschaft b wahr ist, dann verwenden Sie sie", ist Ihr Code in Ordnung und entspricht bis zu einem gewissen Grad der JS-Sprache.

├ähm ... es sei denn, ich ├╝bersehe etwas ... die ├änderungen, die Sie an der Geige vorgenommen haben, geben mir nur noch mehr Recht ... var result ist in allen 3 F├Ąllen immer noch undefined . Und ich bin mir nicht sicher, welchen Fall Sie durch die Erweiterung der primitiven Prototypen voranbringen wollen ...

Ich bin mir ziemlich sicher, dass das Verhalten der Funktion darin bestehen w├╝rde, mit void 0 kurzzuschlie├čen, anstatt einen Fehler zu generieren. (Mir gef├Ąllt Ihre obige Idee, dass im Falle eines fehlenden Mitglieds immer void 0 zur├╝ckgegeben werden sollte).

Was ist die beabsichtigte Ausgabe von ''?.toString ?

@kevinb7 : Was passiert, wenn ccc keine Funktion ist? Mit dem von Ihnen beschriebenen Code m├╝sste __chain immer eine g├╝ltige Funktion zur├╝ckgeben, oder es w├╝rde ein TypeError ausgegeben werden.

Guter Punkt.

@metaweta : Ich w├╝rde mir vorstellen, dass die meisten Leute einen Verweis auf die Funktion toString erwarten w├╝rden, also sehe ich, wo Ihr Punkt ist. Es bricht etwas zusammen, wenn Sie auf die Prototyp-Mitglieder von 0 zugreifen, falsch, oder ''.

:+1:
Angular 2 hat Elvis Operator zu seiner Template-Syntax hinzugef├╝gt

@Metaweta :

Was ist die beabsichtigte Ausgabe von ''?.toString?

Wenn Sie ''?.toString() meinten, w├Ąre es:

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

Probe

Vielleicht k├Ânnten wir daf├╝r einen Strohmann-Vorschlag zusammenstellen

@kevinb7 es existiert bereits: http://wiki.ecmascript.org/doku.php?id=strawman :existential_operator

Ich habe einige schnelle Tests durchgef├╝hrt, um dies zus├Ątzlich zu PropertyAccessExpression als Sonderfall zu implementieren, aber es hat nicht gut funktioniert, da wir wirklich ?. brauchen, um rechtsassoziativ zu sein (anstatt linksassoziativ wie . ) sonst wird der Emitter unn├Âtig komplex.

Es gibt hier einen Kommentar von BrendenEich, der dies ebenfalls widerspiegelt.

Ich habe einige schnelle Tests durchgef├╝hrt, um dies zus├Ątzlich zu PropertyAccessExpression als Sonderfall zu implementieren, aber es hat nicht so gut funktioniert, wie wir es wirklich brauchen. rechtsassoziativ sein (statt linksassoziativ wie .), sonst wird der Emitter unn├Âtig komplex.

@basarat kannst du das bitte n├Ąher erl├Ąutern? Ein Beispiel f├╝r den Unterschied zwischen rechtsassoziativ und linksassoziativ ?. w├Ąre sehr hilfreich f├╝r mich.

@Zlumer

Ein Beispiel f├╝r den Unterschied zwischen rechtsassoziativem und linksassoziativem ?. w├Ąre mir sehr hilfreich.

. bleibt assoziativ, sodass der Ausdruck foo?.bar?.baz in AST wird (wenn wir ?. gleich behandeln):

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

Die ben├Âtigte JavaScript-Ausgabe ist

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

Es ist nur einfacher, diese Ausgabe (insbesondere _rekursiv_) durchzuf├╝hren, wenn wir Folgendes in der AST h├Ątten:

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

Denken Sie nur an _wie w├╝rden Sie den ersten AST in JavaScript umwandeln_ und die Komplexit├Ąt w├Ąre klarer. Hoffe das hilft :rose:

@zlumer , um das zu erg├Ąnzen, was @basarat gesagt hat, ich werde nur das Beispiel 1 + 2 + 3 ausgeben.

Beim Parsen m├╝ssen wir entscheiden, welche dieser Operationen zuerst ausgef├╝hrt wird.

Wenn + ist, wird dies als ((1 + 2) + 3) interpretiert.

Wenn + ist, wird dies als (1 + (2 + 3)) interpretiert.

Man k├Ânnte sich fragen, ob das wirklich einen Unterschied machen w├╝rde. In JavaScript w├Ąre es! Betrachten Sie das Beispiel "hello" + 2 + 3 .

  • Linksassoziativ: (("hello" + 2) + 3) => ("hello2" + 3) => "hello23"
  • Rechtsassoziativ: ("hello" + (2 + 3)) => ("hello" + 5) => "hello5"

(F├╝r den Datensatz verwenden JavaScript/TypeScript Linksassoziativit├Ąt f├╝r den + -Operator.)

@basarat , mein Verst├Ąndnis von dem, was @BrendanEich gesagt hat (und er kann mich korrigieren, wenn ich falsch liege - sorry f├╝r den Ping!) ist _nicht_, dass ?. rechtsassoziativ ist, sondern dass CoffeeScript auf die Eigenschaft f├╝r Sonderf├Ąlle zugreift das Recht von ?. , rechtsassoziativ zu sein. Zum Beispiel wird es parsen

o.p?.q.r.s

als

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

anstatt

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

weil es leichter zu emittieren ist.

Unser AST muss sich gut f├╝r eine vern├╝nftige semantische Analyse eignen, daher kann es sich unser Emissionsverfahren leisten, etwas komplexer zu sein, um diesem Bedarf gerecht zu werden.

@basarat @DanielRosenwasser danke f├╝r die Erkl├Ąrungen. Soweit verstehe ich es, aber bei einer Sache bin ich mir immer noch nicht sicher.
Das linksassoziative ?. ist ziemlich offensichtlich und wird erwartet:

foo?.bar?.baz

Wird (ca.):

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

Aber ich verstehe ├╝berhaupt nicht, wie ein rechtsassoziatives ?. funktionieren w├╝rde. K├Ânnen Sie bitte ein Beispiel geben?

Aber ich verstehe ├╝berhaupt nicht, wie w├╝rde ein rechtsassoziativer ?. Arbeit. K├Ânnen Sie bitte ein Beispiel geben

@zlumer Das Laufzeitverhalten bleibt assoziativ. Ich sprach gerade vom AST, da DanielRosenwasser auch klarstellte: is not that ?. is right-associative, but that CoffeeScript special cases property accesses on the right of the ?. to be right-associative .

Unser AST muss sich gut f├╝r eine vern├╝nftige semantische Analyse eignen, daher kann es sich unser Emissionsverfahren leisten, etwas komplexer zu sein, um diesem Bedarf gerecht zu werden.

@DanielRosenwasser danke f├╝r das Feedback :rose:

@basarat danke, pl├Âtzlich war alles klar :smiley:

Ähnlich wie im Februar-Kommentar von @basarat , I.... _sigh_...

Wenn Sie jedoch dar├╝ber nachdenken, bestehen 99 % der Anwendungsf├Ąlle darin, einen Nullzeiger auf ein Objekt zu pr├╝fen. Ehrlich gesagt, wer macht x?.b?.c , wenn x ein number ist? Es gibt einfach nicht viele reale Anwendungsf├Ąlle f├╝r _lange_ Ketten, wenn wir _nicht_ ├╝ber ein Objekt sprechen (mit der m├Âglichen Ausnahme von string ). Bei kurzen Ketten denke ich, dass wir mit x && x.b oder x === 0 ? null : x.b leben k├Ânnen.

K├Ânnen wir also irgendwie sagen, dass ?. nur auf Objekttypen funktioniert? Jeder andere Typ l├Âst einen Syntaxfehler aus. Und verbieten Sie Funktionsaufrufe in der Kette.

Dann wird das Ganze in a && a.b && a.b.c transkribiert.

@schungx Was ist, wenn ein Mitglied in der Kette ein "beliebiger" Typ ist? Komplett verbieten? Oder einfach durchgehen lassen und das Beste hoffen?

Na, mein Vorschlag? Vollst├Ąndig verbieten. Verdammt unelegant, ich wei├č... :-)

Aber meine Begr├╝ndung:

  1. Dies ist eine Abk├╝rzung, wenn also jemand any verwendet, verwenden Sie einfach die Langschrift.
  2. Wenn jemand TypeScript verwendet, verwendet er/sie es h├Âchstwahrscheinlich f├╝r die Tippunterst├╝tzung, also wird er/sie hoffentlich nicht viele any in der N├Ąhe haben!
  3. any sollte wirklich mit Vorsicht behandelt werden. Die Verwendung solcher Abk├╝rzungen mit einem flexiblen Typ wie any zuzulassen, verlangt wirklich nach Fehlern. Meiner Meinung nach sollten any so begrenzt wie m├Âglich sein. Es ist ein bisschen wie (void *) von C ÔÇô die Tatsache, dass man eine Atombombe bekommt, bedeutet nicht, dass man sie ausl├Âsen muss, nur weil man es kann!

Das w├Ąre ein toller Betreiber!! Besonders f├╝r 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

Ich schlage jedoch eine klarere vor - um nicht zu verwirren? aus dem ? b : c Anweisungen mit a?.b Anweisungen:

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'];

F├╝r die Klammernotation empfehle ich zwei Punkte anstelle eines einzigen, da dies mit den anderen konsistent ist, wenn keine Klammern verwendet werden. Daher ist nur der Eigenschaftsname statisch oder dynamisch ├╝ber Klammern.

Zwei Punkte bedeuten, wenn es null oder undefiniert ist, stoppen Sie die weitere Verarbeitung und nehmen Sie an, dass das Ergebnis des Ausdrucks null oder undefiniert ist. (da d null oder undefiniert w├Ąre).

Zwei Punkte machen es klarer, sichtbarer und r├Ąumlicher, damit Sie verstehen, was los ist.

Dies ist auch kein Herumspielen mit Zahlen - da dies nicht der Fall ist, z

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

├ťber Nummern zwei M├Âglichkeiten: Ihr Anruf kann angenommen werden, aber ich empfehle zuerst eine f├╝r die Kompatibilit├Ąt mit bestehenden Regeln!

  1. Sollte wie jetzt fehlschlagen ( 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. Sollte funktionieren, da es versteht, dass es sich nicht um eine Nummer handelt, die eine Unterkunft von Number.prototype anruft
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

Mit dynamischen Namen:

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

Was denkt ihr Leute?

PS foo?.bar und foo?['bar'] Syntax w├╝rde auch funktionieren.

Die Verwendung der beiden aktuellen Operatoren ? : und ?. kann jedoch in derselben Zeile sehr verwirrend sein.

zB mit ?. und ?['prop']

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

im Gegensatz zu den doppelten Punkten .. und ..['prop']

var a = { x: { y: 1 } };
var b = condition ? a..x..y : a..y..z;
var c = condition ? a..['x']..['y'] : a..['y']..['z'];
Welcher sieht f├╝r dich klarer aus?

Sehr interessant. :+1:

IMHO, zwei Punkte werden verwirrender sein. Es gibt Sprachen, in denen zwei Punkte einen Bereich darstellen (z. B. 1..4 ) und TypeScript wird diese Funktion m├Âglicherweise in Zukunft hinzuf├╝gen.

Ein Fragezeichen hat auch die semantische Bedeutung von Unsicherheit oder Bedingung und zwei Punkte vermitteln nicht dieselbe Bedeutung.

@schungx Fair genug, aber es w├╝rde f├╝r die seltsamen M├Âglichkeiten wie diese helfen: a?['b'] oder diese a?() .

+1 ?

a?['b'] und a?() verhalten sich gut in coffeescript, und f├╝r mich sehen sie gut aus.

Aber andererseits bin ich vielleicht einfach Kaffeeskript-blind.

+1 Ruby hat gerade den Existenzoperator https://twitter.com/mikepack_/status/657229703443451904 implementiert. Typoskript ben├Âtigt dies auch, unabh├Ąngig von der spezifischen Syntax.

Dies w├╝rde den Code sauberer machen ­čĹŹ

+1 Brauche das!

Bitte, implementieren ?. -Operator, wie es C# tut

+1 Das habe ich lange vermisst

+1
so h├Ąsslich zu schreiben: someVariable && someVariable.someMember
wenn Sie schreiben k├Ânnten: someVariable?.someMember

+1, das w├Ąre gro├čartig .... (meistgesuchtes Feature f├╝r mich)

+1, es ist eine gute Idee!
Nur wenn das Objekt kompliziert ist, wird der Ausdruck voller ? sein. nach jeder Eigenschaft (var result=myValue?.a?.b?.c?.d?.e;), wenn ich einen Wert der letzten erhalten muss (var result=?myValue.abcde;).

+1 ÔÇô Dies ist wohl eine der gr├Â├čten Funktionen von CoffeeScript und bei weitem die begehrteste TypeScript-Funktion meines Teams, nachdem wir einen Gro├čteil unseres Codes von CS nach TS konvertiert haben.

+1 aber das ist zu komplex:

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

Ich mag das:

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

Der Typ von x?.y?.z ist immer der Typ des Feldes z . Nat├╝rlich muss der Typ nullable sein und der tats├Ąchliche Wert kann null sein. Wenn es nicht null ist, muss es vom Typ des Felds z sein.

+1 Dies w├╝rde gut zur Vision von Typescript passen, die Entwicklung umfangreicher komplexer JS-Projekte zu erleichtern.

Irgendwelche Updates dazu? Ist dies ein Fall, in dem die Community f├╝r dieses Feature stimmt, damit es ber├╝cksichtigt wird? Oder wurde es in Betracht gezogen, aber es gibt einige technische Herausforderungen?

Bisher keine Aktualisierungen, da die Einf├╝hrung einer neuen Syntax auf Ausdrucksebene ohne irgendeinen Vorschlag des ECMAScript-Komitees gef├Ąhrlich ist.

Siehe https://github.com/Microsoft/TypeScript/issues/16#issuecomment -57645069.

Hier ist eine aktuellere Diskussion ├╝ber existenzielle Operatoren (viele Gedanken, sieht aber nicht nach viel Aktion aus):

Wo soll ich "+1" schreiben, um es zu ES zu bringen?

@msklvsk ESDiscuss

Schlie├če dies vorerst. Da es nicht wirklich etwas TypeScript-spezifisches gibt, das dies auf Ausdrucksebene erfordern w├╝rde, sollte diese Art von gro├čer Operator├Ąnderung eher im ES-Spezifikationskomitee als hier stattfinden.

Die allgemeinen Stolperfallen f├╝r eine Neubewertung w├Ąren ein konkreter ES-Vorschlag, der die n├Ąchste Stufe erreicht, oder ein allgemeiner Konsens des ES-Ausschusses, dass dieses Feature f├╝r lange Zeit nicht stattfinden w├╝rde (damit wir unsere eigene Semantik definieren und vern├╝nftig sein k├Ânnten sicher, dass sie "gewinnen" w├╝rden).

das Leben ist schei├če

Eigenst├Ąndiges :+1:s l├Âschen. Bitte nutzen Sie die GitHub-Reaktionsfunktion oder senden Sie Blumen und S├╝├čigkeiten an Ihren n├Ąchsten TC39-Vertreter.

Sobald ich mich in Coffeescript und Swift daran gew├Âhnt habe, gibt es kein Zur├╝ck mehr. TS ist f├╝r mich tot, so wie es derzeit aussieht.

@algesten Ich kann swift zustimmen, wenn wir die Sprache selbst betrachten, nicht sicher ├╝ber die langfristige Unterst├╝tzung coffescript (ich verwende CoffeScript in Produktionsprojekten). Wir k├Ânnen sicher sein, dass Sprachanalysetrends f├╝r Juni 2016 wie diese hier sind, wo wir deutlich sehen k├Ânnen, was in letzter Zeit bei coffescript vor sich geht, w├Ąhrend TypeScript in den letzten Jahren das schnellste Wachstum verzeichnet hat:

TypeScript: Abgesehen von Go oder Swift ist TypeScript die am schnellsten wachsende Sprache, die wir in den letzten Jahren beobachtet haben. Das von Microsoft unterst├╝tzte JavaScript-Superset und die Angular 2-Stiftung haben im zweiten Quartal in Folge erhebliche Gewinne erzielt und sind von Platz 31 auf Platz 26 gesprungen. Das war die gr├Â├čte einzelne ├änderung in einer der Top-30-Sprachen und der zweitgr├Â├čte Sprung insgesamt (Standard ML, 7 Pl├Ątze). Tats├Ąchlich ist TypeScript jetzt auf Platz 26 mit Erlang gleichauf, einen Platz hinter Powershell und vier hinter CoffeeScript, das knapp au├čerhalb der Top 20 liegt. Die Frage, vor der die Sprache steht, ist nicht, ob sie wachsen kann, sondern ob sie das Momentum hat die Top 20 in den n├Ąchsten zwei bis drei Quartalen zu knacken und dabei Namen wie CoffeeScript und Lua zu ├╝berspringen.

Bis 2014 waren die coffescript Trends mehr als positiv, wie Sie hier sehen k├Ânnen, dann begann der R├╝ckgang.

Mit dem neuen Typoskript 2.0 ist die strikte Nullpr├╝fung (undefiniert) ein Muss, da Sie sonst keine Funktionsverkettung verwenden k├Ânnen!

Dies sollte in der n├Ąchsten Version von ECMAScript enthalten sein. In Anbetracht dessen, dass dies in Vanilla-JavaScript noch n├╝tzlicher w├Ąre als in TypeScript, und in Anbetracht der Tatsache, dass die Implementierung nat├╝rlich eine Pr├╝fung auf undefiniert oder null im Gegensatz zu einer Wahrheitspr├╝fung w├Ąre, sollte es f├╝r TC39 trivial sein, es hinzuzuf├╝gen.

Die einfache Implementierung und eine, die in JavaScript idiomatisch w├Ąre, w├Ąre einfach, einen Kurzschluss zu machen, wenn entweder null oder undefiniert auftritt, und undefiniert zur├╝ckzugeben.

@bterlson macht das Sinn? Wie stehen die Chancen, dass ein solcher Vorschlag angenommen wird?

Einer der gro├čen Vorteile von Typoskript ist ÔÇ×die Zukunft wird Ihnen heute geschenktÔÇť. Dies ist eine der Funktionen, die mich ├╝berrascht hat, die nicht bereits vorhanden sind.

Ich hoffe, dass es bald hinzugef├╝gt wird, da Funktionsverkettung eine beliebte Redewendung ist und die strenge Nullpr├╝fung nicht mehr funktioniert, es sei denn, das ?. Betreiber hinzugef├╝gt.

TS 2 wunderbare Nullpr├╝fung hat es von einem sch├Ânen Muss gemacht!

Beim Durchlesen dieses Threads bin ich etwas ├╝berrascht, dass dies nicht mehr Aufmerksamkeit von den Betreuern erh├Ąlt.

In einer idealen Welt sollte TypeScript den Weg f├╝r ES weisen und nicht umgekehrt. Im Ernst, wo w├Ąre TypeScript jetzt, wenn das TS-Team immer darauf gewartet h├Ątte, dass ESx ein Feature oder eine Syntax vorschl├Ągt und fertigstellt?

Diese Syntax ist wirklich ein "Muss", wie andere darauf hingewiesen haben. Es sind in diesem Thread bisher sogar einige gute Vorschl├Ąge eingegangen. Ich denke, die Umsetzung sollte diesen Erwartungen entsprechen.

  • Im Allgemeinen sollte ein Ausdruck a?.b zur Kompilierzeit g├╝ltig sein, wenn und nur wenn a.b g├╝ltig ist.
  • Es sollte jeden Ausdruck in der Kette nur einmal auswerten.
  • Es sollte ein Kurzschluss sein.
  • Wenn die Ausf├╝hrung einen mittleren Ausdruck mit dem null oder undefined erreicht, sollte dieser Wert der R├╝ckgabewert sein.

Was sind Ihrer Meinung nach die Teile, die zu Meinungsverschiedenheiten f├╝hren k├Ânnen, wenn ES sie spezifiziert?

F├╝r a?.b sehe ich keine Konflikte mit bestehender (und zuk├╝nftiger?) Syntax. Wenn der Parser das Token ?. findet, kann er es als ÔÇ×sicheren NavigationsoperatorÔÇť behandeln (mit Erwartungen wie von @cervengoc beschrieben).

Syntaxkonflikte treten nur auf, wenn a?(b) und a?[b] zugelassen werden, da diese auch als Beginn eines tern├Ąren Operatorausdrucks ?: interpretiert werden k├Ânnten. Aber f├╝r den Anfang denke ich, dass diese beiseite gelegt werden k├Ânnten, und die Unterst├╝tzung nur der a?.b -Syntax w├╝rde bereits viele Entwickler gl├╝cklich machen!

In einer idealen Welt sollte TypeScript den Weg f├╝r ES weisen und nicht umgekehrt.

In Bezug auf die Syntax auf Ausdrucksebene sind wir absolut anderer Meinung. Es gibt einen Grund, warum ein Komitee einen Standard vorantreibt ÔÇô nicht, damit einmalige Aktionen eines Spielers einseitig ├╝ber die Zukunft von JavaScript entscheiden k├Ânnen.

Diese Syntax ist wirklich ein "Muss", wie andere darauf hingewiesen haben.

Wenn dies ein Muss f├╝r TypeScript ist, ist es auch ein Muss f├╝r JavaScript! Bringen Sie Ihre Bedenken erneut vor das ECMAScript-Komitee .

Was sind Ihrer Meinung nach die Teile, die zu Meinungsverschiedenheiten f├╝hren k├Ânnen, wenn ES sie spezifiziert?

Zumindest denke ich, dass es Meinungsverschiedenheiten dar├╝ber geben wird, ob die Syntax zu null oder undefined , wenn sie auf diese Werte st├Â├čt, oder immer zu undefined . Es wird auch Streit dar├╝ber geben, ob irgendeine Form von Klammersyntax unterst├╝tzt wird oder nicht. Es stellt sich auch die Frage, wie sich a?.b.c verh├Ąlt. Es gibt auch die Frage von ?. vs. .? vs. a.b? . Es stellt sich die Frage, welche Auswirkungen dies auf den Operator delete hat.

Der ES DIscuss-Thread dazu ist ├╝ber 100 Kommentare lang. An Zweideutigkeit mangelt es nicht! Es ist leicht, ein Beispiel isoliert zu betrachten und zu denken, dass es nicht unz├Ąhlige Sonderf├Ąlle geben kann. Es gibt. Das ist wahrscheinlich der Grund, warum sich noch niemand bei TC39 daf├╝r eingesetzt hat und _auch_, warum wir es nicht eilig haben, ein Feature hinzuzuf├╝gen, bei dem es viele Unklarheiten dar├╝ber gibt, wie es sich verhalten sollte.

Ich entschuldige mich, ich habe den erw├Ąhnten Thread nicht gelesen, ich werde ihn mir auf jeden Fall ansehen, um mehr zu sehen.

Wir sehen das etwas anders. ├ťber das Komitee, meiner ehrlichen Meinung nach ist dies einer der Hauptgr├╝nde, warum JavaScript niemals _gut_ sein wird. Nur um ein Beispiel zu nennen, viele der erfolgreichsten Programme, die ich gesehen habe (wie Total Commander oder IrfanView), sind erfolgreich, weil sie von EINER Person gepflegt und entworfen werden und nicht von einem *Komitee". Nat├╝rlich ist dies nicht vollst├Ąndig richtiges Beispiel, aber ich bin mir fast sicher, wenn Sie zB alleine den kompletten ES6 entworfen h├Ątten, dann w├Ąre die Welt jetzt ein besserer Ort.

Au├čerdem sind die Unklarheiten, die Sie erw├Ąhnt haben, zu 99 % _theoretisch_ und f├╝r die Entwicklerseite irgendwie irrelevant. Wen w├╝rde es interessieren, was es zur├╝ckgibt, null oder undefined ? W├Ąhlen Sie einfach eine aus, und wir werden sie so verwenden.

Alles in allem stehen Sie und dieser Ausschuss auf einer anderen Seite als die meisten von uns, und die Dinge auf dieser Seite sind normalerweise komplexer als sie wirklich sind. Und dies kann, gelinde gesagt, zu einer gewissen Kontraproduktivit├Ąt f├╝hren. Nehmen Sie es nicht pers├Ânlich, aber nach meiner Erfahrung im Allgemeinen sollten einige Leute besser ├Âfter aus dem Konferenzraum kommen und sich etwas Code ansehen.

Nat├╝rlich nichts f├╝r ungut, nimm nichts pers├Ânlich, ich habe gro├čen Respekt vor dir und dem gesamten TS-Team, denn du hast die clientseitige Entwicklung vieler Entwickler revolutioniert, mich eingeschlossen, und danke dir f├╝r all deine Arbeit. Wir sind nur ein bisschen entt├Ąuscht ├╝ber dieses spezielle, denke ich.

Ein letzter Gedanke. Ich bin den erw├Ąhnten ES-Thread durchgegangen, und eines ist absolut sicher: Sie verkomplizieren es zu sehr. Sie wollen etwas entwerfen, das f├╝r jedes Szenario gut ist.

Ich pers├Ânlich w├Ąre mit einem Conditional Member Access Operator vollkommen zufrieden und gl├╝cklich. Ben├Âtigen Sie keinen bedingten Aufruf, keine bedingte Indexsignatur, m├╝ssen Sie nicht jedes ausgefallene Szenario unterst├╝tzen, das g├╝ltiger JS-Code ist. Das ist alles. Aber stattdessen werden sie wahrscheinlich weiterhin dort sitzen und diskutieren, wie sie alles auf einmal erledigen k├Ânnen, was ein gro├čartiger Plan ist, aber wir werden am Ende des Tages nichts haben.

Alles in allem stehen Sie und dieser Ausschuss auf einer anderen Seite als die meisten von uns, und die Dinge auf dieser Seite sind normalerweise komplexer als sie wirklich sind.

Ich glaube nicht, dass Sie den wahren Status von Ryan oder TC39 genau wiedergeben. Ryan und das TypeScript-Team haben sich sehr klare Designziele f├╝r TypeScript gesetzt. Eines der urspr├╝nglichen und immer noch sehr aktuellen Ziele ist, dass TypeScript eine Obermenge von JavaScript ist. Nicht die Sprache, die die Leute gerne h├Ątten (zB Dart, Haxe). Was die Syntax angeht, hat das TypeScript-Team auf die harte Tour gelernt, wie teuer es ist, sie vorab zu erfinden (z. B. Module). Wir steuern auch kopf├╝ber auf eine Herausforderung mit privaten Klassenmitgliedern zu, bei der die vorgeschlagene ES-Syntax v├Âllig inkompatibel mit der Syntax ist, die TypeScript verwendet. Warum? Denn was an der Oberfl├Ąche unkompliziert aussieht, ist angesichts der Laufzeitherausforderungen einer Sprache unm├Âglich zu erreichen.

TC39 hat meiner Meinung nach JavaScript "gespart". ES4 wurde aufgegeben, nicht weil es an guten, innovativen Ideen mangelte, sondern weil es das Internet kaputt machen w├╝rde. TC39 hat sich in Form gebracht, sie haben ihre Diskussionen geteilt und waren v├Âllig offen in ihren Diskussionen und wie sie Entscheidungen treffen und uns ES2015 geliefert haben, das ES4 sehr ├Ąhnlich ist, aber das Internet nicht kaputt gemacht hat. Es ist erstaunlich, dass wir im Wesentlichen JavaScript-Laufzeiten haben, die Code von vor 10 Jahren problemlos ausf├╝hren, aber viele signifikante Verbesserungen der Sprache unterst├╝tzen. ES2016 war die Ruhe vor dem Sturm. ES2017 hat eine "angemessene" Menge an Funktionalit├Ąt und ├änderungen und einen klaren Steuerungsprozess, der in die richtige Richtung weist.

Auf der ÔÇ×anderen SeiteÔÇť der Dinge zu stehen, hat meiner Meinung nach also eindeutig funktioniert. Was die Zweckm├Ą├čigkeit von ÔÇ×must haveÔÇť-Features ├╝bertrifft.

@kitsonk Ich meinte "andere Seite" nicht negativ und vor allem wollte ich nicht die Arbeit herabsetzen, die in TypeScript oder ES6 gesteckt wurde. Dar├╝ber hinaus ist das Beste an TypeScript meiner Meinung nach, dass es wirklich ein klares Designziel hatte und hat, und dass es wie viele andere Open-Source-Sachen gut davor gesch├╝tzt ist, zu einem Chaos zu werden.

Ich wollte nur sagen, dass genau diese Funktion ein klares Beispiel daf├╝r ist, wo eine Gruppe genialer Leute am Ende Dinge ├╝berdenken und ├╝berm├Ą├čig verkomplizieren wird, anstatt einfach den einfachen Weg zu gehen und einige Einschr├Ąnkungen zu akzeptieren, wie z. B. keine Unterst├╝tzung von Aufrufen oder Indexsignaturen usw Jemand in diesem Forum hat sogar vorgeschlagen, diese Syntax in Aufgaben zu verwenden, was ziemlich verr├╝ckt ist. Ich denke immer noch, dass dieses Ph├Ąnomen in diesem Sinne kontraproduktiv ist.

Ich verstehe, dass es auf Ihrer Seite ├Ąrgerlich ist, dass beispielsweise private Mitglieder mit dem endg├╝ltigen ES6-Konzept nicht mehr kompatibel sind. Aber auf der anderen Seite hatten wir es. Weit vor ES6. Und das ist der Hauptpunkt von unserer Seite. Grob gesagt ist es uns egal, wie Sie es schaffen, den entsprechenden Code daf├╝r auszugeben, wir verwenden ihn einfach gl├╝cklich. Dasselbe gilt f├╝r Module und alles. Wir (oder zumindest ich) haben diese Schmerzen nicht gesehen, wovon du sprichst, wir waren immer gl├╝cklich mit privaten Mitgliedern oder Modulen.

Diese spezielle Funktion ist in CoffeScript enthalten, wie ich dar├╝ber gelesen habe. Warum m├╝ssen wir einfachen Entwickler immer Kompromisse bei der Auswahl einer Plattform/Library/Plugin etc. eingehen? Ich meine immer . Das ist irgendwie nervig. Hier haben wir eine gro├čartige Sprache, die gro├čes Potenzial hat, die alle anderen Teilnehmer (einschlie├člich ES!) komplett hinter sich l├Ąsst und die einen gro├čen Teil der clientseitigen Entwicklung erfolgreich revolutioniert hat, und wenn es um dieses "einfache" Feature geht ( Ich meine zumindest den Teil des Mitgliederzugriffs), wir h├Âren, dass es nicht implementiert wird, bis ES sich dazu verpflichtet.

Ich wollte den Leuten kurz mitteilen, dass dieses Feature beim heutigen TC39-Meeting von Stufe 0 auf Stufe 1 verschoben wurde.

Relevantes Commit: https://github.com/tc39/proposals/commit/cb447642290a55398d483f5b55fb7f973273c75d
Tagesordnung des Meetings: https://github.com/tc39/agendas/blob/master/2017/01.md

Beeindruckend! das ist riesig!

Einige "├ťberraschungen", die ich hier sehe (ohne zu sagen, dass ich anderer Meinung bin, nur Dinge, die wir wahrscheinlich anders gemacht h├Ątten, wenn wir dies fr├╝her getan h├Ątten):

  • null wird nicht aus einem a?.b -Ausdruck erzeugt: Wenn a gleich null ist, erzeugt dies stattdessen undefined
  • ~Propagation in verketteten Punkten: a?.b.c.d l├Âst nicht aus, wenn die Eigenschaften b und c undefined sind ~ Ryan kann nicht lesen
  • ~Propagation in Gegenwart von Parens : sogar (a?.b).c l├Âst nichts aus, wenn b undefiniert ist~ Ryan kann nicht lesen
  • ~Die Weitergabe erfolgt sogar bei Methodenaufrufen: a?.b.c().d gibt undefined zur├╝ck, wenn der Aufruf von c null zur├╝ckgibt ~ Ryan kann nicht lesen
  • Der Operator delete wird unterst├╝tzt
  • Klammersyntax a?.[x] wird unterst├╝tzt
  • Funktionsaufrufsyntax func?.(...args) wird unterst├╝tzt, auch f├╝r Nicht-Methodenaufrufe (!)

Ich w├╝rde erwarten, dass sich in diesen Bereichen bis Stufe 2 etwas ├Ąndern wird.

Ich denke, Coffeescript hat es richtig gemacht.

a?.bc l├Âst aus, wenn b nicht definiert ist.

a?() und a?[0] sind beide gut.

  • Ausbreitung in verketteten Punkten: a?.bcd wird nicht ausgel├Âst, wenn b- und c-Eigenschaften nicht definiert sind
  • Fortpflanzung in Gegenwart von Klammern: gerade (a?.b).c l├Âst nicht aus, wenn b undefiniert ist
  • Die Weitergabe erfolgt sogar bei Methodenaufrufen: a?.bc().d gibt undefiniert zur├╝ck, wenn der c-Aufruf null zur├╝ckgibt

Diese Punkte scheinen mir nicht genau zu sein. Aus dem Vorschlag:

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

Wow, das habe ich total ├╝berlesen. Du hast recht. Aktualisierung

@algesten aus dem urspr├╝nglichen Vorschlag:

a?.()

b?.[0]

S├╝ss. der Operator kann dann als ?. bezeichnet werden.

Hier finden einige zus├Ątzliche Gespr├Ąche statt: https://github.com/estree/estree/issues/146

Ein Zitat, das gut zutreffen k├Ânnte: ┬źMache einfache Dinge leicht und schwierige Dinge m├Âglich ┬╗. Unterst├╝tzen Sie daher vielleicht die h├Ąufigsten F├Ąlle gut, w├Ąhrend Sie (zumindest anf├Ąnglich) die komplizierten/seltenen F├Ąlle ├╝berspringen, w├Ąhrend sie mit l├Ąngerer (bestehender) Syntax immer noch "manuell erledigt" werden d├╝rfen.

Nur meine zwei Cent

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

zu:

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

@cedvdb v├Âllig andere Semantik - Ausnahmen, die in Gettern ausgel├Âst werden, sollten keine Koaleszenz verursachen

@RyanCavanaugh ja .. Ich habe das nicht durchdacht.

Ist dies jetzt auf dem Radar f├╝r die Implementierung oder wird das TS-Team warten, bis der ES-Vorschlag weiter voranschreitet?

Es steht auf unserer Shortlist; Wir haben immer noch ein paar Fragen/Bedenken, aber im kommenden Monat sollten Sie diesbez├╝glich Bewegung sehen.

Ich bin mir nicht sicher, woher der Kommentar von @mhegazy stammt - die Anzahl der offenen Fragen zum TC39-Vorschlag ist zu gro├č, als dass wir hier sinnvoll arbeiten k├Ânnten. Insbesondere Fragen dazu, wie null und undefined interagieren und welche Syntax tats├Ąchlich unterst├╝tzt wird, m├╝ssen zuerst gekl├Ąrt werden. Stufe 2 ist ein absolutes Minimum, und wir w├╝rden Stufe 3 angesichts der Auswirkungen auf das Laufzeitverhalten bevorzugen.

Funktioniert dieser einfache Code?

a == undefined ? expression : undefined

expression bedeutet ax, a[x], a(x), delete k├Ânnte hier auch generiert werden

dann wird a?.b?.[c]?.(d) generiert

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

scheint alle Regeln von RyanCavanaugh zu durchlaufen


Wenn Sie den Operator == hassen, k├Ânnte es auch a === undefined || a === null sein

@zh99998 du _musst_ == hassen, weil '' und 0 auch gleichgesetzt werden. Es wird fast argumentiert, dass das Laufzeitverhalten eine Art ├ťberpr├╝fung von (typeof value === 'object' || typeof value === 'function' || typeof value === 'symbol') && value !== null sein sollte, was jetzt ziemlich komplex wird.

Wie @RyanCavanaugh sagte, ist es unwahrscheinlich, dass es Fortschritte macht, bis der TC39-Vorschlag daf├╝r mindestens Stufe 2 oder 3 erreicht hat.

Ich sehe == nur gleich null und undefined als
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equality_comparisons_and_sameness

und Test in der Chrome-Konsole bestanden:

'' == undefined
false
0 == undefined
false

@kitsonk undefined erzwingt nur Null und umgekehrt. Kein anderer Wert wird auf undefined oder null gezwungen.

Sie scheinen mit falschen Werten verwirrt zu sein. 0 und "" sind zwar falsch, werden aber niemals auf null oder undefiniert gesetzt.

== impliziert Zwang. null == 0 ist falsch, weil nichts au├čer undefined auf null zwingen kann. Gleiches gilt f├╝r undefined == 0 .

Ein anderes Beispiel k├Ânnte sein

    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

Du bekommst das Bild.

Ich sehe viele Versuche mit tern├Ąren Operatoren, aber jede Implementierung, die mehrmals auf dieselbe Eigenschaft verweist, k├Ânnte zu unerwarteten Nebenwirkungen f├╝hren.

Gl├╝cklicherweise verf├╝gt JavaScript ├╝ber IIFEs, sodass Sie das Ergebnis eines Accessors in einem Funktionsparameter speichern, beliebig oft darauf verweisen und es nie mehr als einmal auswerten k├Ânnen. In meinem Beispiel unten erstelle ich ein coalesce -Lambda, das mehrmals anstelle eines Ausdrucks aufgerufen werden kann, der ?. -Operatoren enth├Ąlt.

Eine Sache, mit der sich die Sprachimplementierer befassen m├╝ssten, sind Array- und Funktionsaufrufe mitten in einem Ausdruck. Ich denke, der Compiler k├Ânnte diese Situationen erkennen und diese Ausdr├╝cke einfach an das Ende des Coalesce-Aufrufs anh├Ąngen.

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]

Beachten Sie, dass kein tats├Ąchlicher globaler Name namens "coalesce" erforderlich ist. Dieser Code k├Ânnte direkt in jeden Ausdruck eingebunden werden. Es k├Ânnte jedoch das Aufbl├Ąhen reduzieren, indem es ihm einen Namen gibt.

Ich mache mir keine allzu gro├čen Sorgen um die Syntax, die f├╝r den Operator verwendet wird, oder ob die Sprachimplementierer auf einen Standard warten m├Âchten. Ich dachte nur, ich w├╝rde einen anderen Ansatz zeigen.

Dies bringt auch die Notwendigkeit eines ?? -Operators mit sich. In C# ersetzt dies jeden null -Ausdruck durch das, was rechts davon steht.

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";

Leider erfasst Wahrhaftigkeit zu viele Grenzf├Ąlle ( 0 , false , etc.). Wenn Sie mit einem Null-Coalesce-Operator ( ?. ) arbeiten, m├Âchten Sie etwas Spezifisches f├╝r null -ness.

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

@jehugaleahsa , in Ihrem Beispiel mit Coalesce m├╝sste es eine M├Âglichkeit geben, Funktionsaufrufe und Memberzugriff zu verhindern, wenn die vorherige Pr├╝fung null zur├╝ckgegeben hat. Im x?.f()-Beispiel sollte f nicht aufgerufen werden, wenn x null ist.

@bschlenk Ich glaube nicht, dass ich damit einverstanden bin. Ich denke, es sollte mit einer Nachricht wie null is not a function fehlschlagen, aber das liegt nicht an mir, denke ich.

Die j├╝ngste Flut an Kommentaren, die m├Âgliche Wege zur Implementierung des Operators beschreiben, ist etwas seltsam.
Die Implementierung ist wahrscheinlich ein gel├Âstes Problem.

Wenn Sie interessiert sind, gibt es die idx-Bibliothek , die dem Verhalten des Operators ?. sehr ├Ąhnlich ist, obwohl sie auch viele Details des geplanten Operators ignoriert. Wie auch immer, ihre Spezifikationen f├╝r die Kompilierausgabe k├Ânnten f├╝r jeden interessant sein, der sich fragt, wie dieses Zeug implementiert werden k├Ânnte.

TS k├Ânnte so etwas ausgeben oder es k├Ânnte etwas v├Âllig anderes ausgeben, aber ich glaube nicht, dass wir hier darauf warten. Es wurde hier oft gesagt, dass TS den Betreiber nicht bekommt, bis der ES-Vorschlag in die eine oder andere Richtung geht.

Es ist die Semantik, die noch einige Unbekannte hat, die hier und hier aufgelistet sind.

Seien Sie versichert, dass wir dies korrekt implementieren und hier keine weiteren 100 Kommentare ben├Âtigen, um herauszufinden, was || und ? ... : ... tun. Wie @noppa feststellte, warten wir nur darauf, dass die ES-Spezifikation fertiggestellt wird.

https://github.com/babel/babel/pull/5813 (zugeh├Ârig zu babylon PR ) wurde gerade in Babels preset-stage-1 eingebunden. Die Spezifikation befindet sich nat├╝rlich noch in Phase 1, aber dies wird dazu beitragen, sie voranzutreiben.

Vielleicht irre ich mich, aber ich habe in diesem Thread keinen offensichtlichen Link zum tc39-Vorschlag gesehen, also hier f├╝r die zuk├╝nftigen Leser: https://github.com/tc39/proposal-optional-chaining

FYI optional Chaining wird n├Ąchste Woche bei TC39 https://github.com/tc39/agendas/blob/master/2017/07.md sein

@jehugaleahsa Ich denke, du hast Recht und ich werde n├Ąchste Woche ?? auf der TC39 pr├Ąsentieren. Sie k├Ânnen den Vorschlag hier verfolgen: https://github.com/gisenberg/proposal-nullary-coalescing

Ich sehe, dass die optionale Verkettung beim TC39 abgedeckt wurde ... Wie war das Urteil?
Hoffentlich hat es gereicht, um das in Typescript voranzubringen ­čśë

@markwhitfeld Aus der Zusammenfassung der Notizen :
Optionale Verkettungsoperatoren: Bleibt auf Stufe 1, kommt sp├Ąter mit klareren Definitionen f├╝r verschiedene Optionen und Antworten auf Feedback

Vollst├Ąndige Notizen hier: https://github.com/rwaldron/tc39-notes/blob/master/es8/2017-07/jul-27.md#13iia -optional-chaining-operator

Es gibt noch offene Fragen dazu, wie sich der Operator verhalten soll, also scheint es, als w├Ąre er noch nicht in einem Zustand, in dem er zu TypeScript hinzugef├╝gt werden kann.

Aus diesen Notizen geht hervor, dass der Ausschuss keine Ahnung hat, wie die vorgestellten Optionen funktionieren. Ich h├Ątte gedacht, dass sie sich vor der Diskussion ├╝ber die Vorschl├Ąge informiert h├Ątten, die sie diskutieren wollten. Ich sch├Ątze, es wird noch eine Weile dauern, bis ich strenge Nullpr├╝fungen aktivieren kann.

Ich hoffe sehr, dass sie sich f├╝r Option 2/4 entscheiden (was ohnehin der aktuelle Stand des Vorschlags ist).

15. Juli 2014 - 4. September 2017, noch nichts

@frankfvb Sie haben die Ausgabe eindeutig nicht gelesen.

Es gab viele Diskussionen, die das Kernteam zu der Annahme veranlasst haben, dass es unklug w├Ąre, an dieser Stelle zu implementieren, bis weitere Fortschritte beim ECMAScript-Vorschlag vorliegen, die sich direkt auf die Funktionalit├Ąt dieser Funktion in TypeScript auswirken w├╝rden.

Seit der letzten Sitzung des ECMAScript-Standardausschusses befindet sich der Vorschlag in Phase 1 , da er einige sehr grundlegende Fragen zur Implementierung enth├Ąlt. Obwohl es keine feste Regel ist, implementiert TypeScript nur Vorschl├Ąge der Stufe 3. Es implementiert manchmal Vorschl├Ąge der Stufe 2, wenn sie der Meinung sind, dass dies von entscheidender Bedeutung ist, und die potenzielle Verwendung in TypeScript die Entwicklung des Standards vorantreibt.

Ich bin mir nicht sicher, wie klarer die Leute dar├╝ber sein k├Ânnen.

Wie ich bereits sagte , steht dies auf unserer Shortlist. wir warten auf TC39, um eine Art Konsens ├╝ber die Semantik des Operators zu erzielen. Wir w├╝rden es hassen, es zu ver├Âffentlichen und dann Benutzer zu brechen.

Dies ist nicht der Thread, um die TC39-Diskussion wieder aufzuw├Ąrmen

Wenn Sie sich zu dem Vorschlag ├Ąu├čern m├Âchten, kommentieren Sie ihn an der entsprechenden Stelle . Ich habe auch Meinungen, aber sie in diesem Thread fallen zu lassen, wird nichts tun.

Ich habe etwas Einfaches geschaffen, das meinen aktuellen Bed├╝rfnissen entspricht. Es funktioniert nur in einer Kette, in der jeder Link ein Eigenschaftsname ist, sodass der Zugriff auf ein Element in einem Array (z. B.) nicht unterst├╝tzt wird.

Implementieren eines wirklich einfachen Elvis-Operators in TypeScript

Auch wenn Sie Lodash/Unterstrich haben, k├Ânnen Sie bereits _.get(Book, 'author.name.firstName') verwenden, was das tut, was dies will

Bearbeiten: Anscheinend ist dies ein schlechter Rat wegen Typproblemen mit der Methode _.get() . Siehe Kommentar unten

@tolgaek , _.get hat schlechte Typisierungen, selbst mit diesen besseren Typisierungen ( noch nicht zusammengef├╝hrt , wegen Autoren) kann Typoskript den Ergebnistyp nur dann definitiv ableiten, wenn die Objekttiefe 1 ist, in allen anderen F├Ąllen ist es any und muss zur Laufzeit ├╝berpr├╝ft werden

Auf der anderen Seite kann Typoskript mit Elvis Operator in der Lage sein, den Ergebnistyp in Objekten mit beliebiger Tiefe abzuleiten, deshalb freue ich mich auf Elvis Operator

Oh, ich verstehe, ich wusste nicht, dass es ein Tippproblem gibt. Danke @BjornMelgaard

@mhegazy kann diese Funktion nicht zuerst implementiert und als experimentelle Funktion markiert werden? Ich denke, die Leute sollten kein Problem haben, wenn die Spezifikation in der experimentellen Funktion ge├Ąndert wird.

Elvis ist nicht am├╝siert, so lange zu warten.

Es ist in Babel7 gelandet. Typoskript, wir laufen langsam. Jemand, bitte, mach das m├Âglich.
:)

@gs-akhan das Babel-Plugin implementiert eine alte Version des Vorschlags von vor einigen Monaten. Seitdem gab es ├änderungen an dem Vorschlag (einschlie├člich einer wesentlichen ├änderung, wie der Operator geparst wird), und es wird wahrscheinlich weitere ├änderungen geben, bevor das Feature Stufe 2 erreicht (geschweige denn Stufe 3), also jeder Code, der mit dem aktuellen babel geschrieben wurde Plugin k├Ânnte kaputt gehen, wenn das eigentliche Feature ver├Âffentlicht wird. Babel implementiert absichtlich vorgeschlagene Features, bevor sie stabil sind, damit die Spezifikationsautoren und andere interessierte Parteien das Feature wie vorgeschlagen ausprobieren k├Ânnen. Nur weil Babel ein Feature implementiert hat, bedeutet das nicht, dass es auf eine Art und Weise implementiert werden kann, die in Zukunft keine Breaking Changes erfordert.

@alangpierce Das macht Sinn. Danke

Ich verstehe, dass dies ein wirklich, wirklich netter Betreiber ist, aber ihn verf├╝gbar zu haben, bevor seine Regeln ausgeb├╝gelt wurden, ist ein Fu├čgewehr, und das werden wir nicht tun. Das Laufzeitverhalten des Operators ist noch im Fluss; Wenn Sie heute Code schreiben, k├Ânnte er morgen auf eine Weise nicht mehr funktionieren, die nicht sofort ersichtlich ist - vielleicht seltene Abst├╝rze, vielleicht Datenbesch├Ądigung, wer wei├č? Ein wenig Geduld erspart Ihnen jetzt in ein paar Monaten viel Schmerz.

Beginnen zu glauben, dass dieses Ticket gesperrt (nicht geschlossen) werden sollte, bis die Spezifikation fertig ist.

Wann wird die Spezifikation fertig sein?

@oliverjanik Den aktuellen Spezifikationsentwurf finden Sie hier . Es gibt einen Tagesordnungspunkt, um den Vorschlag beim n├Ąchsten TC39-Treffen (26.9.-28.9.) auf Stufe 2 vorzur├╝cken. Ich werde diese Folien zu dieser Zeit pr├Ąsentieren. Personen, die fr├╝hzeitig eine ├ťberpr├╝fung vornehmen und Feedback geben m├Âchten, melden Probleme bitte im Proposal-Repository .

Vielen Dank @gisenberg , dass du dich f├╝r dieses Thema f├╝r uns eingesetzt hast! Ich habe dar├╝ber nachgedacht, eine zusammenfassende Pr├Ąsentation zusammenzustellen, um die Optionen rund um den Bediener zu kl├Ąren, die beim TC39-Meeting verwendet werden k├Ânnten, um Verwirrung zu vermeiden, aber Sie haben dies bereits getan. Tolle Arbeit!
Vielleicht ist eine andere Sache, die f├╝r die TC39-Konversation (und das Foliendeck) von Vorteil sein k├Ânnte, die Semantik und Syntax des Operators in anderen Sprachen zu betrachten. Obwohl andere Sprachen nicht unbedingt vorschreiben sollten, wie es in Javascript funktionieren sollte, w├Ąre es hilfreich, den Operator ├Ąhnlich wie in anderen Sprachen zu halten, um Verwirrung zu vermeiden.
Viel Gl├╝ck f├╝r n├Ąchste Woche!!!

Entschuldigen Sie, dass ich wieder einmal etwas vom Thema abgekommen bin, aber ich dachte, einige Leute hier k├Ânnten es interessant finden, dass es in Flow jetzt m├Âglich ist, einigerma├čen funktionierende Typdefinitionen f├╝r sichere Getter-Funktionen wie _.get hinzuzuf├╝gen.

Beispiel: flowtype.org/try

Nicht das sch├Ânste St├╝ck Code aller Zeiten und es unterscheidet nicht richtig zwischen null und undefiniert, aber ansonsten scheint es ganz gut zu funktionieren.

AFAIK das einzige, was TS fehlt, um dasselbe zu tun, ist so etwas wie $NonMaybeType .
Nat├╝rlich nicht, dass es diesen Operator ├╝berfl├╝ssig machen w├╝rde, ich fand das nur cool.

Dies erreichte Stufe null beim letzten undefined -Meeting aufgrund von Bedenken hinsichtlich der syntaktischen Konsistenz in Bezug auf den Zugriff von Klammern vs null -ausgewerteter Operand) sowie offene Fragen dar├╝ber, welche Art von Ausdr├╝cken no-op'd sein d├╝rfen (zB x.?b() wenn x.b ein number ist)

(stimme ­čÄë ├╝ber diesen Kommentar ab, um faule Fr├╝chte zu werfen)

Danke, dass Sie uns das mitteilen. Ach wie schade. Vielleicht muss der Geltungsbereich eingeschr├Ąnkt werden, damit er einfacher, aber dennoch n├╝tzlich ist?

Vielleicht muss der Geltungsbereich eingeschr├Ąnkt werden, damit er einfacher, aber dennoch n├╝tzlich ist?

Das ist die Herausforderung, der sich TC39 gegen├╝bersieht, und obwohl es beschissen ist, muss ich zugeben, dass ich froh bin, dass die Leute das durchmachen. Es ist wirklich schwierig f├╝r sie, eine ziemlich komplexe Level-Syntax einzuf├╝hren, und tats├Ąchlich verursacht die schwache Typisierung der Sprache in diesem Fall tats├Ąchlich eine erhebliche Menge an Grenzf├Ąllen, die angegangen werden m├╝ssen, oder Sie erhalten Code, der ­čĺą geht, was nicht geht ist f├╝r niemanden gut. Ich glaube nicht, dass Sie durch die Einf├╝hrung eines Operators wie diesem seinen Geltungsbereich einschr├Ąnken k├Ânnen. Es w├Ąre einfacher f├╝r die Implementierer, 90┬á% der F├Ąlle abzudecken, aber ich glaube nicht, dass ┬»\_(Ńâä)_/┬» f├╝r die restlichen 10┬á% g├╝ltiger Code ist.

Leute, mehr als 3 Jahre sp├Ąter w├╝rde ich sagen, es ist an der Zeit, dem Komitee ÔÇ×Fuck youÔÇť zu sagen und es auf unsere eigene Weise zu tun, was auch immer f├╝r TypeScript idiomatisch ist. Diese Funktion kann ohne statische Eingabe sowieso nicht richtig funktionieren.

Erstellen Sie eine TypeScript-Implementierung mit einer Syntax, die ausdr├╝cklich nicht mit dem TC39-Vorschlag kompatibel ist. Sobald ES einen Safe-nav-Operator erh├Ąlt, hat TypeScript zwei Optionen: eine mit beschissener Semantik, die mit ES kompatibel ist, und eine, die an das Typsystem gebunden ist. Dies bedeutet, dass Sie den TS-Safe-Nav-Operator nicht mit einem beliebigen "Typ" verwenden k├Ânnen, und das ist in Ordnung.

@notsnotso Typescript soll JS nicht brechen, daf├╝r ist Coffeescript da.

Vielleicht ist eine gute L├Âsung:

  • ganz einfach umsetzen? Operator f├╝r ungeduldige Entwickler, als experimentelles Feature (wie Decorator), mit Warnung - es WIRD Ihren Code in Zukunft brechen
  • warten Sie weitere 3 Jahre, wenn der Standard geschrieben wird, implementieren Sie es als nicht-experimentelles Feature. Tutorial schreiben, was kaputt sein k├Ânnte. Sogar mit statischer Typisierung ist es m├Âglich, Warnungen zu schreiben, wenn Leute Code mit einer neuen Operatorimplementierung kompilieren.
    "Mach es auf unsere eigene Weise, was auch immer f├╝r TypeScript idiomatisch ist" ist kein Fall, denn in 3 Jahren werden die Leute mit dem Problem konfrontiert sein, dass ts elvis nicht so funktioniert wie in js.

Ich bin nicht ├╝berrascht, dass das nicht geklappt hat, um ehrlich zu sein. In meinem Original
post, wies ich auf die Mehrdeutigkeit bez├╝glich Indizierung, Funktionsaufrufen usw. hin.
Ehrlich gesagt, je mehr ich ├╝ber ?. nachdenke, desto mehr f├╝hlt es sich so an, als ob es das nicht w├Ąre
geh├Âren in JavaScript, da es undefined hat.

Ich h├Ątte viel lieber ein allgemeineres Dienstprogramm, das dieses Problem l├Âst
und mehr. Ein Gedanke, den ich hatte, war so etwas wie ein Inline- try/catch
Ausdruck ( let x = try a.b.c else 0 ) in Verbindung mit einem Operator that
auf ÔÇ×nullyÔÇť (z. B. x ?? 1) und nicht auf ÔÇ×falseyÔÇť (z. B. x || 1) gepr├╝ft.
Sie w├╝rden sie also folgenderma├čen kombinieren: try a.b.c ?? 0 else 0 . Es ist wortreich, ja,
aber es hei├čt im Grunde: Versuchen Sie, abc auszuwerten und ob das Ergebnis null oder ist
undefined , gib 0 zur├╝ck. Wenn a oder b undefined ist und eine Ausnahme ausgel├Âst wird,
Fangen Sie es und geben Sie eine 0 zur├╝ck.

Eine Alternative w├Ąre, die Klausel else optional zu machen, was standardm├Ą├čig der Fall ist
undefined . Dann k├Ânnten Sie den Ausdruck schreiben als: let x= (try a.b.c) ?? 0 . Das ist verdammt kompakt, vermeidet Mehrdeutigkeiten und bietet mehr
Allzweckl├Âsung, die andere Probleme l├Âsen kann.

Ich sage nicht, dass wir stattdessen darauf dr├Ąngen sollten; Alles, was ich sage, ist da
sind Alternativen zu ?. und wir sollten unsere M├Âglichkeiten wirklich erkunden, bis wir
Finden Sie eine, die gut zur JavaScript-Sprache passt.

Am Donnerstag, 5. Oktober 2017 um 7:51 Uhr, Dmitry Radkovskiy [email protected]
schrieb:

@notsnotso Typescript soll JS nicht brechen, das ist was
Coffeescript ist f├╝r.

ÔÇö
Sie erhalten dies, weil Sie erw├Ąhnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/Microsoft/TypeScript/issues/16#issuecomment-334441781 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/ABTgPilbZfuKc2egdBrYfdTHHeDl3F6Sks5spMLLgaJpZM4CNapf
.

@zlumer netter Witz. Allerdings w├╝rde eine TS-spezifische Funktion Javascript nicht besch├Ądigen.

@jehugaleahsa Ich mag deinen Vorschlag und er ist in anderen Sprachen zu finden. Ich denke, es w├╝rde gut f├╝r TS funktionieren.

Ich werde sagen, dass ich die starke Notwendigkeit, zu warten, bis ECMAScript den Operator akzeptiert, nicht wirklich verstehe. TypeScript f├╝gte Klassen, Module und Lambdas hinzu, lange bevor sie ihren Weg in ECMAScript fanden. Tats├Ąchlich war/ist eines der erkl├Ąrten Ziele von TypeScript die Erprobung experimenteller JS-Funktionen. TypeScript, das seine eigene Implementierung bereitstellt, w├╝rde zweifellos dazu beitragen, diese Diskussionen im Komitee zu informieren.

Ihr wart bereit, bahnbrechende ├änderungen vorzunehmen, bevor das Komitee schlie├člich eine andere Richtung einschl├Ągt. Ich verstehe nicht wirklich, warum diese Funktion so anders ist.

Auch async/await wurde schon fr├╝h in TypeScript eingef├╝hrt.

Allerdings w├╝rde eine TS-spezifische Funktion Javascript nicht besch├Ądigen.

Es wird so etwas wie ÔÇ×TS-spezifisches FeatureÔÇť nicht geben, bitte ├╝berpr├╝fen Sie TypeScript Design Goals f├╝r weitere Informationen.

TypeScript kommt an, bevor ES auf einen hellen Pfad geht, es k├Ânnte einige existieren,Sie werden nur aus Kompatibilit├Ątsgr├╝nden beibehalten.

TypeScript f├╝gte Klassen, Module und Lambdas hinzu, lange bevor sie ihren Weg in ECMAScript fanden.

Und gerade Module sind ein riesiges Debakel, das noch immer f├╝r Verwirrung sorgt. Das ist ein Beispiel, das das TypeScript-Team wiederholt als Beispiel f├╝r einen _Fehler_ und zu fr├╝hes ├ťberspringen verwendet hat. Wir haben jetzt auch private Felder, f├╝r die ich in den letzten 5 Jahren dankbar war f├╝r private , aber es wird kein Ende der Verwirrung stiften.

Auch hier waren Dekorateure unter der Flagge verf├╝gbar, aber jetzt, wo Dekorateure tats├Ąchlich Stufe 3 erreichen, wird es eine Neuimplementierung und einen Codebruch f├╝r TypeScript erfordern. Deshalb k├Ânnen diese Dinge _nicht_ f├╝r wahrscheinlich gehalten werden.

Auch async/await wurde schon fr├╝h in TypeScript eingef├╝hrt.

Sobald der ECMAScript-Vorschlag Stufe 3 erreicht hat.

Niemand benimmt sich schlecht, aber wenn dieses Gespr├Ąch nur im Kreis gef├╝hrt werden kann (was w├Ąre, wenn es eine Flagge g├Ąbe? Ja, wir sind uns der Flaggen bewusst) oder off-topic (was, wenn TS aufh├Ârt, JS zu sein? Nein, f├╝nf Jahre sp├Ąter ├Ąndern wir uns nicht unsere Gedanken darauf), wir m├╝ssen es nicht haben. Wir sagen seit ungef├Ąhr 3 Jahren, dass wir dies genau dann implementieren werden, wenn das ES-Komitee seine Semantik sperrt.

Auch hier ist das Proposal-Repo https://github.com/tc39/proposal-optional-chaining und Sie k├Ânnen den Fortschritt dort verfolgen. Wir werden offline arbeiten, um zu versuchen, die Chancen des Vorschlags beim n├Ąchsten TC39-Treffen zu verbessern, weil wir wirklich wollen, dass dies auch durchgeht.

Update: Wir haben heute Nachmittag bei TC39 Stufe 2 erreicht!!!

Optionale Verkettung ist Stufe 3

Diesen nur zur Feier kurz aufsperren

Hurra!

Nicht spammen...

Sie k├Ânnen ein Emoji senden, das Ihre Gef├╝hle ausdr├╝ckt

Nicht spammen...

Sie k├Ânnen ein Emoji senden, das Ihre Gef├╝hle ausdr├╝ckt

Au├čerdem macht es Spa├č, zuzusehen, wie die Emoji-Z├Ąhlung so steigt. Ich habe noch nie gesehen, dass ein Kommentar zu einem Thema so schnell so viel Popularit├Ąt erlangt hat!

Ich habe ein kleines Video der Echtzeit-Updates aufgenommen https://youtu.be/JLBrgPjeGhc

Kann mich jemand von diesem Ding abmelden?

@DanielRosenwasser Falls du nicht scherzt, oder f├╝r alle anderen, die sich abmelden wollen und nicht wissen wie, suchst du diesen Button in der rechten Seitenleiste:

image

Ganz zu schweigen von einem Link in der E-Mail:

image

Es war ein Witz, ich arbeite an dem Vorschlag.

@RyanCavanaugh nach dem Freischalten dieses Problems:
martian

Wirklich aufgeregt, das endlich landen zu sehen! ­čÄł ­čÄë

Ich kann den passenden VSCode-Quick-Fix kaum erwarten ­čść

image

Ich gehe zu @ @RyanCavanaugh , weil er diesen Thread wahrscheinlich nicht abonniert hat und ich unh├Âflich sein m├Âchte! (und @DanielRosenwasser zur Sicherheit)

@kitsonk Sei kein Arsch. Es steht den Menschen frei, sich abzumelden und nicht bel├Ąstigt zu werden.

@kitsonk , Warum sollten RyanCavanaugh oder DanielRosenwasser diesen Thread abbestellen? Ryan hat dieses Problem freigeschaltet und Daniel hat drei Kommentare ├╝ber Ihnen beantwortet.

Selbst wenn sie abgemeldet wurden, besteht keine Notwendigkeit, mehr Benachrichtigungsm├╝digkeit durch Spam zu verursachen.

Anscheinend ist GitHub ein schrecklicher Ort f├╝r sarkastischen Humor, gee ...

Ein gro├čes Dankesch├Ân an unsere Champions bei TC39, die die fiesen Details dieser neuen Sprachfunktion herausgefunden haben!

thanks

Ich denke, @kitsonk hat nur Spa├č gemacht, genau wie ich es irgendwie war. W├Ąhrend wir angesichts der Aufregung ein wenig albern sind, ist dies eine sanfte Erinnerung daran, die Dinge gem├Ą├č dem CoC h├Âflich zu halten.

@DanielRosenwasser
Muss ich das mal ausprobieren? Oder @rbuckton hat noch einen anderen existierenden Zweig daf├╝r ­čÖő­čĆ╗ÔÇŹÔÖé´ŞĆ


Ok, ich habe es verstanden https://github.com/microsoft/TypeScript/commits/optionalChainingStage1 ­čĄŽ­čĆ╗ÔÇŹÔÖé´ŞĆ

Ja, das ist leider ziemlich veraltet.

Mir ist gerade aufgefallen, dass dieses Thema vor 5 Jahren er├Âffnet wurde. :erstaunt:

@rbuckton

Ja, das ist leider ziemlich veraltet.

K├Ânnte ich das mal anprobieren?

Entschuldigung @jhpratt @MatthiasKunnen Ich habe vergessen, dass wir auf GitHub nicht alle denselben Kontext teilen. Ich bin hier schon lange herumgesprungen und habe Zeit mit Ryan und Daniel IRL verbracht und kurz an dem j├╝ngsten Ereignis teilgenommen, das Anlass zu meinem missverstandenen Insider-Witz gab. Entschuldigung.

Diese ganze Ausgabe zeigt jedoch eine interessante Arch├Ąologie der Designprinzipien von TypeScript. Ryan sprach es zu einer Zeit an, in der TypeScript _vielleicht_ tats├Ąchlich eine Syntax in Betracht gezogen hat, die vor der ernsthaften ├ťberlegung in ECMAScript lag. Es war jedoch ungef├Ąhr zu dieser Zeit, als TypeScript intern einige Lektionen ├╝ber die Vorhersage der ES2015-Syntax lernte, die schwerwiegende Auswirkungen auf die Sprache hatten. Das Team beschloss, die Aufnahme erst in Betracht zu ziehen, wenn ein TC39-Vorschlag f├╝r Stufe 3 vorlag.

W├Ąhrend @RyanCavanaugh darauf eingehen kann und ich wei├č, dass er nahe daran war, was mit dem Vorschlag passiert ist, vermute ich, dass es unwahrscheinlich gewesen w├Ąre, dass das, was das Team 2014 implementiert h├Ątte, zu 100 % mit dem aktuellen Vorschlag f├╝r Phase 3 kompatibel gewesen w├Ąre . Obwohl es sicherlich ein Fest ist, sollten Sie auch dankbar sein, dass wir keinen 5-j├Ąhrigen TypeScript-Code mit einem sicheren Navigationsoperator haben, der nicht vollst├Ąndig mit dem Verhalten im Vorschlag vereinbar w├Ąre.

­čÖĆ

westwing

Ist dies der Moment, um das Label Waiting for TC39 zu entfernen? ­čĄö

Ist dies der Moment, um das Label Waiting for TC39 zu entfernen? ­čĄö

Und f├╝gen Sie ship-it hinzu

wowow

Endlich. Ich habe mich buchst├Ąblich nach optionalen Verkettungen heute erkundigt und mich gefragt, wann es Phase 3 sein wird, und bam! Danke an alle, die daran gearbeitet haben, es durchzubringen!

Wie kann man diesen Thread stumm schalten? :)

@opnksyn Wenn Ihnen die Spam-Aufregung egal ist, gibt es eine Funktion, um benachrichtigt zu werden, wenn dieses Problem geschlossen wird. Dadurch wird verhindert, dass alle Kommentare in Benachrichtigungen wie der gerade erstellten angezeigt werden ­čśä

image

image

Irgendeine Emit-L├Âsung bereits definiert?
So etwas k├Ânnte interessant sein:

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()))));

Ich bevorzuge, was Babel tut, da es unn├Âtige Funktionsumf├Ąnge vermeidet:

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);

Ich bevorzuge, was Babel tut, da es unn├Âtige Funktionsumf├Ąnge vermeidet:

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);

Dem stimme ich zu, @ExE-Boss. Ich denke, dass es ideal ist, unn├Âtige Funktionsumf├Ąnge zu vermeiden (auch wenn es den kompilierten Code etwas h├Ąsslich macht).

Wenn es um kompilierten Code geht, sollten Leistung und Einhaltung der ES-Spezifikation definitiv die Lesbarkeit ├╝bertreffen.

Gibt es einen Grund, warum der von Babel kompilierte Code sowohl null als auch mit void 0 mit dreifachem Gleichheitszeichen anstelle eines einfachen == null verglichen wird?

Gibt es einen Grund, warum der von Babel kompilierte Code sowohl null als auch mit void 0 mit dreifachem Gleichheitszeichen anstelle eines einfachen == null verglichen wird?

@proteria Ich habe mir nur kurz den optionalen Verkettungscode f├╝r __Babel__ angesehen ; Es scheint, dass, wenn Sie die Option loose ├╝bergeben und auf einen wahren Wert setzen, die strengen Gleichheitspr├╝fungen nicht erzeugt werden

Das liegt an document.all (oder, um es pedantisch zu sagen, dem [[IsHTMLDDA]]-internen Steckplatz ), einer Eigenart, die in der Sprache f├╝r Abw├Ąrtskompatibilit├Ąt eine Sonderbehandlung erh├Ąlt.

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

Im optionalen Verkettungsvorschlag

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

aber document.all == null ? void 0 : document.all.foo w├╝rde f├Ąlschlicherweise void 0 zur├╝ckgeben. Im losen Modus wird dieses Detail der Spezifikation aus Gr├╝nden der Einfachheit/Leistung/generierten Codegr├Â├če verworfen, da die meisten Leute sowieso nicht mit document.all umgehen m├╝ssen.

Der document.all -Fall k├Ânnte doch sicher etwas Besonderes sein? Es sollte nicht viel zus├Ątzlichen Code erfordern, nur ein paar Zeilen, um das Objekt und die Eigenschaft zu ├╝berpr├╝fen.

Abgesehen davon, dass document.all einer Variablen zugewiesen werden kann und das Nachverfolgen, wo es verwendet wird, ein Typsystem erfordert, weshalb Babel standardm├Ą├čig Folgendes ausgibt:

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

Das ist mir bewusst. Babel hat kein Typensystem, TypeScript schon. Vielleicht ist es nicht so einfach, wie ich es klingen lasse, aber ich kann mir vorstellen, dass es bereits Code f├╝r bestimmte Situationen gibt, der in der Lage ist, die Nutzung zu verfolgen.

Tats├Ąchlich ben├Âtigen Sie kein Typsystem, um document.all -Variablen zu verfolgen, da das spezielle Verhalten tats├Ąchlich auf HTMLAllCollection und nicht document.all liegt.

Sie sollten also nur in der Lage sein, einen instanceof HTMLAllCollection -Check zu machen, und Sie werden golden sein.

Ja, aber... warum hast du instanceof gemacht, wenn du auch nur === null || === void 0 machen kannst? Das ist sicher einfacher.

Sicher - ich habe nur darauf hingewiesen, dass Sie kein Typsystem ben├Âtigen, um document.all zu verfolgen :)

Pers├Ânlich bin ich versucht zu sagen, brechen Sie es einfach und sehen Sie, wer sich beschwert, aber es ist in der Spezifikation, also ist es am einfachsten, sich einfach daran zu halten.

@noppa Es kann zur Kompilierzeit ausgef├╝hrt werden. Wenn foo instanceof HTMLAllCollection true ist, geben Sie foo === null || foo === void 0 aus, andernfalls k├Ânnen wir foo == null _sicher_ ausgeben.

@G-Rath Ob es Ihnen gef├Ąllt oder nicht, veraltet bedeutet nicht, dass es nicht funktionieren sollte. TypeScript soll mit JavaScript kompatibel bleiben.

@jhpratt Aber das widerspricht derzeit den TypeScript Design Non-Goals .

Au├čerdem m├╝ssten Sie immer noch foo┬á===┬ánull┬á|| foo┬á===┬ávoid┬á0 f├╝r alles tun, dem HTMLAllCollection zugewiesen werden k├Ânnte, z. any oder object , also denke ich nicht, dass es sich wirklich lohnt.

Ich nehme an, Sie beziehen sich auf Nicht-Ziel (5)

F├╝gen Sie Laufzeittypinformationen in Programmen hinzu oder verlassen Sie sich darauf, oder geben Sie basierend auf den Ergebnissen des Typsystems unterschiedlichen Code aus. Ermutigen Sie stattdessen Programmiermuster, die keine Laufzeitmetadaten erfordern.

Obwohl ich zustimme, dass dies sicherlich je nach Typ unterschiedlichen Code ausgeben w├╝rde, dient dies nur dazu, die Codegr├Â├če zu reduzieren. Wie Sie bereits betont haben, ist es jedoch nicht ganz so einfach, nach HTMLAllCollection zu suchen.

Um fair zu sein, hat TS _has_ einen potenziellen Minifier abgelehnt, der Typinformationen verwendet, und dies h├Ąngt (irgendwie) zusammen ÔÇô der Hauptgrund f├╝r die Ausgabe von == null ist die Reduzierung der Codegr├Â├če basierend auf Typinformationen.

Wenn dies _nicht_ implementiert ist, w├Ąre es gro├čartig, wenn das lang-Team eine Option zu tsconfig hinzuf├╝gt, die der "loose"-Option von Babel ├Ąhnelt.

Nach einer schnellen ├ťberpr├╝fung konvertiert terser automatisch foo === null || foo === undefined in foo == null , was aufgrund dieses Randfalls nicht sicher ist.

Wenn dies nicht implementiert ist, w├Ąre es gro├čartig, wenn das lang-Team eine Option zu tsconfig hinzuf├╝gt, die der Option "loose" von Babel ├Ąhnelt.

Dementsprechend verwenden viele von uns TypeScript f├╝r Build-Tools und f├╝r mobile Anwendungen, von denen sich keine ├╝ber Browsereinschr├Ąnkungen Gedanken machen muss!

Tats├Ąchlich verwenden wir sowohl TS als auch Babel zusammen, also sollte eine dieser Optionen vielleicht darin bestehen, den Operator an Babel/die zugrunde liegende Laufzeit zu ├╝bergeben!

@fbartho

Tats├Ąchlich verwenden wir sowohl TS als auch Babel zusammen, also sollte eine dieser Optionen vielleicht darin bestehen, den Operator an Babel/die zugrunde liegende Laufzeit zu ├╝bergeben!

Ich verstehe diesen Kommentar nicht. Sie ben├Âtigen keine zus├Ątzlichen Optionen, um den Operator an Babel weiterzuleiten; Wenn Sie TypeScript f├╝r Babel eingerichtet haben, haben Sie bereits noEmit: true , das bereits _alles_ an Babel durchgibt.

Der TypeScript-Implementierung von @Zarel Babel fehlen mehrere Funktionen, auf die sich unsere Codebasis bereits verlassen hat, darunter Namespaces und Const-Enumerationen. Wir verwenden TSC mit aktiviertem Emit und wenden Babel als zweite Transformation an. (Wir arbeiten daran, die Namensr├Ąume loszuwerden, aber es ist unklar, ob wir jemals in der Lage sein werden, alle nicht ├╝bereinstimmenden Funktionen loszuwerden.)

Leute, die zu diesem Thread kommen, sollten mit der fr├╝heren Ank├╝ndigung von Phase 3 beginnen und die dort beginnenden Kommentare lesen (geben Sie GitHub die Schuld daf├╝r, dass es Tonnen von Benutzerinhalten versteckt, ohne dass es eine einfache M├Âglichkeit gibt, alles zu laden).

Tolles Feature - "optionale Verkettung" / "sichere Navigation". Besonders im strengen TypeScript-Modus. Sch├Ân zu h├Âren, dass dies bald umgesetzt wird. ÔŁĄ´ŞĆ

Das hat mich hierher gebracht und ich hoffe, dass es unterst├╝tzt wird. Nur ein Anwendungsfall:

Erwartet in TypeScript 3.7.

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

VS

Derzeit in TypeScript 3.5.

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

Funktioniert das ohne Fehler? Oder ist das immer noch ein TypeError: Cannot read property 'setAttribute' of null. ? Die ? -Operation. sollten weitere Ketten nach null / undefined abgebrochen werden.

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

Ich erwarte folgendes:
Wenn das HTML-Element nicht existiert (null). Die Konsole sollte One und Two protokollieren, und es wird nicht versucht, die Methode setAttribute aufzurufen. (Keine Fehler).
Hab ich das richtig verstanden?

@domske FYI, das ist nicht unbedingt eine TS-Funktion; es ist eine JS-Funktion.

Gem├Ą├č dem TC39-Vorschlag lautet die Syntax:

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

Die Diskussion hat begonnen, wieder im Kreis zu gehen, also sind wir wieder im gesperrten Zustand.

Ich bitte wirklich jeden, der versucht ist, einen Kommentar in einem mehr als 100 Kommentare langen GitHub-Thread zu hinterlassen, sich wirklich dazu zu verpflichten, zuerst alle vorherigen Kommentare zu lesen. Wahrscheinlich finden Sie dort Ihre Frage und die Antwort darauf!

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen