Rust: Ternären Operator entfernen

Ich stimme zu. Ich habe mich gefragt, warum wir auch den ternären Operator hatten.

Einverstanden. Ich wünschte, ich hätte JS zu einer Ausdruckssprache gemacht. Die große Aussage/Ausdrucksspaltung motiviert ?: aber Rust ist davon frei, und wenn-sonst genügt.

/Sein

Als sehr intensiver Benutzer des ?:-Operators in C/C++ bevorzuge ich die kompakte Syntax. Ich denke auch, dass es besser formatiert wird, wenn der Ausdruck zu lang ist, um in eine einzelne Zeile zu passen:

let x = some_very_long_condational
     ? if_true
     : if_false

let x = if some_very_long_condational 
     { if_true}
     else { if_false}

Die Syntax kann meiner Meinung nach noch schlimmer werden, wenn if_true und if_false nicht in eine einzige Zeile passen. Wo soll zum Beispiel die Zahnspange platziert werden.

Nur meine zwei Cent.

Ich mag:

let x = if some_very_long_condational { 
                 if_true
           } else { 
                 if_false
           }

Es fügt einige zusätzliche Zeilen hinzu (die "else line" und die letzte Klammer), aber es hält es sauber und Sie können so viel Code hinzufügen, wie Sie möchten.

Ich verwende den ternären Operator häufig in C++, aber ich denke, die Syntax ist schlecht. Sie müssen das erkennen? und : mitten in einem Meer von anderen Token, um zu sehen, dass es sogar eine Bedingung ist. Mit Ausdruck-wenn Sie das führende Token haben, das dem Leser anzeigt "hier kommt eine Bedingung".

Nun, ich bevorzuge immer noch die Syntax des Operators ?: . Ich finde Ihre Wahl der Formatierung zu ausführlich, insbesondere für die einfachen Fälle, in denen if_true und if_false ein einziger Ausdruck sind (im Gegensatz zu mehreren Anweisungen, die auf einen Ausdruck enden).

Trotzdem werde ich nicht sehr stark widersprechen, wenn der Operator ?: entfernt wird.

Ich verwende auch überall ?: , aber ich denke immer noch, es wäre eine gute Idee, es zu entfernen - es gibt zwei (!) ASCII-Sigillen in unserer Ausdruckssyntax frei. Denken Sie an all die anderen unglaublich kryptischen Dinge, die wir mit ihnen machen könnten.

Eine nicht kryptische Verwendung wäre, sie als Teil des Prädikatsnamens zuzulassen.
ZB "empty?()" statt "is_empty()".

@marijnh ++ :)

Mir persönlich ist das egal. Igor plädierte in https://mail.mozilla.org/pipermail/rust-dev/2010-November/000110.html für Ternär

Dies wurde in Pull-Req #1705 durchgeführt.

    return parent.index_of(child_a) < offset_b ? -1 : 1

sieht unendlich besser aus als

    return if parent.index_of(child_a) < offset_b {
        -1 
    } else {
        1
    }

Wenn wir diesbezüglich pythony sein müssen,

return -1 if parent.index_of(child_a) < offset_b else 1

wäre viel besser.

Ich stimme zu, ich verstehe nicht, warum es entfernt werden musste... Bitte zwingen Sie Rust-Benutzer nicht, unnötig umfangreichen / ausführlichen Code zu schreiben, wenn eine solche gängige Praxis (ternärer Operator) in den meisten, wenn nicht allen Sprachen existiert.

Wie auch immer, es ist fertig, aber ich wollte nur meine Stimme zu denen hinzufügen, die einen saubereren Codestil unterstützen.

Ich vermisse auch diese Syntax

Ich denke, hier sind drei Verschwörungseffekte am Werk, nämlich

1) "Die große Aussage/Ausdrucksspaltung" (@BrendanEich);
2) Zwang von Nicht-Booleschen in booleschen Kontexten;
3) Selbst 'dynamische' Sprachen erhalten heutzutage keine 'dynamische Syntax' (echte Makros) und 'dynamische Semantik' (a la Pythons from __future__ import division ).

(1) bedeutet, dass sich if ... then ... else ... etw grundlegend von ... ? ... : ... , was eine völlig entbehrliche Unterscheidung ist. Es gibt Randfälle wie return , aber insgesamt ist die Unterscheidung nicht erforderlich.

(2) bedeutet, dass Sie in vielen Sprachen beliebige Ausdrücke als Tests verwenden können; das sieht nur praktisch aus, solange du noch deine erste Sprache verwendest und wird nervig, sobald du mit deiner zweiten beginnst. Wie oben in dieser Reddit-Diskussion erwähnt , ist es nicht klar, warum eine leere Liste entweder false oder true – schreiben Sie einfach if ( d.length == 0 ) ... und Sie haben _so_ viel Klarheit gewonnen!

(3) bedeutet, dass Sie an dem hängen bleiben, was Ihnen das Sprachkomitee gibt, und was auch immer das ist, die Sprache wird wahrscheinlich daran festhalten, bis jemand vorbeikommt, die Codebasis teilt oder umschreibt und ihr einen neuen Namen gibt. Es könnte anders sein; es könnte Sprachen geben, die beispielsweise use 'ternary conditions'; use 'empty lists are false'; zulassen. Dafür gibt es Präzedenzfälle. Natürlich spricht vieles gegen eine solche Flexibilität, denn Sie müssen diese "Abweichungsmarkierungen" immer im Auge behalten und daran denken, sie beim Kopieren und Einfügen eines Programms zu kopieren. OTOH, wenn einfache Benutzer die Sprachsyntax und -semantik einfach ändern und solche Praktiken in installierbare Module vorpacken könnten, könnte dies bei der Entwicklung der Sprache erheblich helfen.

@kevina Manchmal ist Ausführlichkeit keine schlechte Sache, aber ich stimme zu, dass ternäre Operatoren Code sehr gut bereinigen.

@caitp : Was genau ist daran falsch?

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

oder einer meiner persönlichen Favoriten "Umarmungsklauseln"

return 
    if parent.index_of(child_a) < offset_b { -1 } 
    else                                   {  1 }

... oder verwenden Sie eine Übereinstimmung, insbesondere wenn mehrere Bedingungen vorliegen ...

return match parent.index_of(child_a) < offset_by {
  true  => -1,
  false => 1
}

... und natürlich bei Wiederverwendung: einfach in eine Funktion verschieben ...

return parent.is_child_before(offset_b)

Schau dir das an... du hast Optionen... weil _alles_ ein Ausdruck ist.

Niemals in Rost wollte ich mir die _sechs Zeichen_ sparen, die man braucht, um if {} else {} statt zu schreiben
() ? : , plus das Verketten zusätzlicher Bedingungen sieht mit if-as-an-expression viel schöner aus. (Verschachtelte ternäre Operatoren werden sehr schnell unübersichtlich.)

Meiner Meinung nach: Wenn ich if-as-an-expression sehe ich keine Notwendigkeit, so viel unnötigen Leerraum einzufügen. Ich finde auch, dass es sich natürlicher liest als der ternäre Operator, und die zusätzliche Ausführlichkeit hilft, die beiden Klauseln visuell zu trennen. Das ist nur mein $0.02

Ich denke, Sie haben vielleicht falsch gelesen, was ich gesagt habe (und beachten Sie, dass dies einige Zeit her ist)

Ich weise nur darauf hin, dass ich nicht sehe, wie der ternäre Operator in irgendeiner Weise "unendlich besser" aussieht.
Gewöhnliche Formen sind meiner Meinung nach unendlich schöner als Sonderformen.

Der Kommentar besagt, dass Bedingungen-als-Ausdrücke manchmal sehr nützlich sind, im Gegensatz zu bedingten Anweisungen. Das Weglassen der Umarmungsklammern ist nur subjektiv eine Verbesserung

return parent.index_of(child_a) < offset_b ? -1 : 1

vs

return if parent.index_of(child_a) < offset_b { -1 } else { 1 }

@caitp ist der zweite hier wirklich unendlich schlimmer als der erste? Rusts if else ist immer noch ein Ausdruck (keine Anweisung).

Meine Gedanken sind:

• Die zweite scheint für jemanden ohne eine Geschichte anderer Sprachen besser lesbar zu sein und
• Wir wären wahrscheinlich besser dran, die ? Syntax für zukünftigen Zucker im Ärmel zu behalten (vielleicht im Zusammenhang mit Option usw.).

@mitchmindtree total.

Auch hier missverstehen Sie die Aussage des Kommentars.

return if parent.index_of(child_a) < offset_b { -1 } else { 1 } wertet die Bedingung immer noch als Ausdruck aus (und kann somit ein Operand für return ).

Die geschweiften Klammern sind hässlich, aber es geht hauptsächlich um bedingte Ausdrücke, nicht um geschweifte Klammern. Es geht darum, return foo.bar.baz(<conditional operand>) gegen if (<conditional operand>) { return foo.bar.baz(1); } else { return foo.bar.baz(2); } schreiben zu können

Ich denke, was wir wirklich wissen müssen, ist, dass dieses Thema über drei Jahre alt ist. Wenn man bedenkt, dass die Leute in den letzten drei Jahren nicht so sehr Ternaries vermisst haben, kann ich mit Sicherheit sagen, dass sie entfernt bleiben werden.

@caitp hmm Ich bin mir immer noch nicht sicher, ob ich

Bei Rost kann man noch machen

return foo.bar.baz(if cond { 42 } else { 0 })

? (Ich bin mir bewusst, dass Sie nicht über Zahnspangen gesprochen haben, sorry für die Verwirrung :smile_cat: )

Zu dieser Zeit gab es in ToT keine Möglichkeit, dies in Rust zu tun.

Ich habe keine starke Meinung, aber ich möchte nur hinzufügen, dass, wenn ? und : besser für andere Dinge verwendet werden können, warum nicht etwas wie ?? und ?: stattdessen, zum Beispiel cond ?? 43 ?: 0 ?

Warum ändern Sie die Art und Weise, wie Entwickler es seit Dutzenden von Jahren gewohnt sind?

Le sam. 24. Okt. 2015 02:46, Kevin Atkinson [email protected] a
schreiben:

Ich habe keine starke Meinung, aber ich möchte nur hinzufügen, dass ? und kann
besser für andere Danksagungen verwendet werden, warum nicht so etwas wie ?? und ?:
stattdessen. also vielleicht kond ?? 43?: 0.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/rust-lang/rust/issues/1698#issuecomment -150728625.

@RenaudParis Entschuldigung, was ich sagen wollte war: Ich habe keine starke Meinung, aber ich möchte nur hinzufügen, dass wenn ? und : besser für andere Dinge verwendet werden können, warum? nicht stattdessen etwas wie ?? und ?: verwenden, zum Beispiel cond ?? 43 ?: 0 ?

Einer der Gründe, warum der ternäre Operator entfernt wurde, war, dass "?" könnte in Zukunft für etwas anderes verwendet werden. Mein Vorschlag war, einen anderen Betreiber zu verwenden. cond ?? 43 ?: 0 ist immer noch kürzer als if cond {43} else {0} .

Ich denke, es ist richtig, es zu entfernen, aber es wäre nicht so schlimm, wenn für einzelne Ausdrücke keine Klammern erforderlich wären. (Und ja, ich weiß, wie schmerzhaft das im Parser ist, es lohnt sich imho - Lesbarkeit ist sehr wichtig)

z.B

if i ==0 
     return i
else 
      1  

oder auch

if i == 0  return i
    else 1  

Dieses Format ist besser als

 if i == 0   ? return i
      : 1  

oder

if i == 0   
      ? return i 
      : 1  

Verse

if i ==0 {
      return i
}
else {
    1
}      

ziemlich hässlich / schwer zu lesen für etwas so Alltägliches .

Es wird schlimmer, aber leichter zu lesen, wenn Sie eine Entwicklungsrichtlinie gegen ägyptische Hosenträger haben.

if i ==0
{
     return i
}
else
{
     1
 }