Vielleicht a..b| oder a..b]

Ich denke, dies wird in Zukunft den Weg für die neue Art von unvorhersehbaren Fehlern aufgrund eines einfachen Tippfehlers (.. vs ...) öffnen. Besser wäre es .... (4 Stunden). Auf diese Weise ist es weniger fehleranfällig für den menschlichen Faktor, imo.

Ich denke, https://github.com/rust-lang/rfcs/pull/1592 und https://github.com/rust-lang/rfcs/pull/1582 zusammen sprechen für die Verwendung von ..= Syntax statt. Es sei denn, jemand fällt eine bessere Syntax als (head..., tail) um ein Tupel vor einem größeren Tupel zu erweitern.

Ich habe dieses Problem gefunden, weil ich einen _off-by-one- dot _-Fehler in meinem Code hatte, als ich den exklusiven Bereich verwenden wollte.

👎 für die ... Syntax. Ich denke, eine leicht zu verwechselnde Syntax, die Einzelfehler verursacht, wäre eine Waffe.

Die Funktionalität ist jedoch nützlich, daher würde ich sie gerne mit einer anderen Syntax haben, z. B. ..=

Ist die Syntax dafür eine offene Frage? Da ... bereits in Match-Statements steht, nahm ich an, dass das Schiff gesegelt war.

Ich persönlich würde den ... inklusiven Bereich bevorzugen, da es jedoch bereits die .. exklusive Version gibt, sehe ich das Potential für Probleme. Nachdem ich mir #23635 angesehen habe, würde ich .. eher ablehnen und nur ... zulassen.

Ich verwende häufig Inklusivbereiche für das Äquivalent von C-ähnlichen for-Schleifen for i in 0..foo.len() wo es perfekt passt, also würde ich es vorziehen, dass dieser bleibt (ich brauche das, weil Rusts Iteratoren "1-dimensional" sind und oft zu umständlich für die Verwendung mit 2D-Arrays oder nichtlinearer Iteration).

Das Problem mit dem Überlauf für Inklusivbereiche sieht albern aus, aber in der Praxis bin ich nie auf dieses Problem gestoßen, da Rust bei jedem anderen Typ als usize nervig ist. Wenn ich beim Erstellen des Bereichs for i in 0..(len as usize) umwandeln würde, müsste ich i as usize sowieso ein halbes Dutzend Mal innerhalb der Schleife verwenden.

Da diese Syntax immer noch Feature-Gated ist, hoffe ich, dass das Schiff nicht gesegelt ist.

Wenn man bedenkt, dass Swift ... für inklusive und ..< für exklusive Bereiche verwendet, erscheint die Verwendung von ..= für inklusive ziemlich vernünftig.

Ich habe keine nützlichen Erkenntnisse, aber ich möchte, dass Inklusivbereiche den Status "experimentell" verlassen. Als ich Rust By Example durchging, fand ich einen Ausschnitt, der davon profitieren könnte:

fn fizzbuzz_to(n: u32) {
    for n in 1..n + 1 {
        fizzbuzz(n);
    }
}

Hoch ? 😄

Ich möchte einen RFC für a ..= b Syntax und generalisierte Bereiche schreiben. Ich habe einen Diskussionsthread gestartet,

IMHO ..= sieht komisch aus. Swifts Ansatz von ... und ..< sieht für mich besser aus, weil ich die Ellipse den zwei Punkten vorziehe - Ellipse steht für Auslassen und wir lassen die Zahlen zwischen dem Anfang und dem Ende des Bereichs weg.

Ich denke immer noch ... und .. war gut genug. Sie haben 1 Zeichen Unterschied, daher ist der Fehler schwieriger als +/- oder x/y oder was auch immer.

Da ich das selbst vorhin falsch verstanden habe (und so meinen Kommentar gelöscht habe):

Gemäß dem RFC-Prozess von Rust wurde dieser Vorschlag bereits im RFC-Pull-Request 1192 überprüft, diskutiert und genehmigt. Die vorliegende Ausgabe verfolgt die Umsetzung dessen, was dort zuvor beschlossen wurde. In der Diskussion wurden viele der Punkte behandelt, die hier angesprochen werden: alternative Syntax (einschließlich keiner neuen Syntax), der Kontrast zu Rubys ähnlichen Operatoren usw.

Wenn Sie der Meinung sind, dass die Funktion anders sein sollte, müssen Sie meiner Meinung nach denselben RFC-Prozess durchlaufen, da so Änderungen an der Sprache vorgenommen werden. Aber dieses Thema ist nicht der Ort dafür.

@jimblandy vielleicht sollten wir @nikomatsakis diese höfliche Erinnerung und Anleitung in den ersten Kommentar in Really Big Print bearbeiten lassen. 😇

@shepmaster Das wäre wahrscheinlich eine gute Sache, um eine Vorlage hinzuzufügen, die verwendet wird, um _alle_ Tracking-Probleme einzureichen.

Nominierung zur Diskussion/möglicher FCP

Wir haben dies im @rust-lang/lang-Meeting diskutiert. Es herrschte ein allgemeines Gefühl der Unzufriedenheit mit dieser Funktion. Wir dachten darüber nach, sie einzustellen, entschieden uns jedoch, dies vorerst zu verschieben. Es gibt zwei Haupteinwände gegen ... in der jetzigen Form:

• die Verwechslungsgefahr zwischen .. und ... ;
• @aturon hat gedacht, dass es besser wäre, eine "vollständigere" Bereichssyntax zu haben - dies könnte auch in APIs wie btree-Iteration usw. verwendet werden.

Zu diesem Zweck haben wir uns gefragt, ob jemand bereit wäre, einen RFC voranzutreiben, der eine allgemeinere Syntax wie diese ermöglicht, die es den Leuten ermöglicht, genau anzugeben, ob die unteren und oberen Grenzen einschließend oder ausschließend sind. Ich denke, @aturon würde sich freuen, mit jemandem an einem solchen RFC zu arbeiten.

Ich weiß, dass ich eine Weile ins Stocken geraten bin, aber ich habe kürzlich einen Diskussionsthread darüber eröffnet, wie diese voll funktionsfähigen Bereiche in libstd dargestellt werden ( oben verlinkt), aber niemand hat dazu Stellung genommen :(

Mit etwas Input zu den oben genannten Punkten würde ich gerne bei einem neuen RFC helfen.

Ich habe vor kurzem einen Diskussionsthread darüber eröffnet, wie diese voll funktionsfähigen Bereiche in libstd dargestellt werden (oben verlinkt), aber niemand hat einen Kommentar dazu abgegeben :(

Das spiegelt in gewisser Weise ihre Nützlichkeit wider.
Es klingt zwar nach einer netten Idee, willkürliche Inklusiv-Exklusiv-Bereiche zu haben, aber ich bin mir ziemlich sicher, dass alles außer .. und noch weniger ... niemals verwendet werden wird.

@durka

Ich weiß, dass ich eine Weile ins Stocken geraten bin, aber ich habe einen Diskussionsthread darüber eröffnet, wie diese voll funktionsfähigen Bereiche in libstd (oben verlinkt) dargestellt werden können, aber niemand hat einen Kommentar dazu abgegeben :(

Das sieht ungefähr nach dem Ansatz aus, den wir im Sinn hatten, ja.

@petrochenkov

Während es sich nach einer netten Idee anhört, beliebige inclusive-exklusive Bereiche zu haben, bin ich mir ziemlich sicher, dass alles außer .. und in viel geringerem Maße ... niemals verwendet wird.

Um ehrlich zu sein, stimme ich zu, aber ich denke immer noch, dass es sich lohnen könnte, eine allgemeinere Syntax zu verfolgen. Insbesondere denke ich, dass ... suboptimal ist, aber wenn wir zu ..= oder etwas expliziterem übergehen, schadet es wahrscheinlich nicht wirklich, etwas Allgemeineres zu tun, auch wenn es selten vorkommt Gebraucht. Das heißt, wenn wir es systematisch machen, scheint es nicht viel schwieriger zu lernen, und es ist sicherlich so, dass es keine Verwirrung geben würde, ob .. oder ... "mehr Zahlen" bedeutet ".

Das sieht ungefähr nach dem Ansatz aus, den wir im Sinn hatten, ja.

Welcher? Ich habe in meinem Beitrag mehrere Alternativen vorgeschlagen.

Ich möchte oft über Inklusivbereiche iterieren und mochte es wirklich, 0...x anstelle von 0..(x + 1) . Ich verstehe, dass dies zu Einzelfehlern führen kann, aber welche Alternativen haben wir?

Angenommen, die Syntax von Rust könnte ohne Nebenwirkungen frei geändert werden, sehe ich nur einige offensichtliche Muster:

Nimm es so wie es ist

1..4 // 1, 2, 3
1...4 // 1, 2, 3, 4

was IMHO eine gute Lösung ist und auch beim Pattern-Matching verwendet wird.

Ausleihe aus der Mathematik

[1, 4] // 1, 2, 3, 4
[1, 4[ // 1, 2, 3
]1, 4] // 2, 3, 4
]1, 4[ // 2, 3

Dies ist die vollständigste Syntax, verstößt jedoch gegen die gleiche Regel für öffnende und schließende Klammern und ist visuell schwieriger zu analysieren.

Ausleihen von Python

1:1:=5 // 1, 2, 3, 4, 5
1:1:<5 // 1, 2, 3, 4

Dies ist ein bekanntes Muster und könnte auch eine Schrittweite enthalten. Ich weiß nicht, wie der RFC-Prozess funktioniert, aber ich denke, eine Schrittweite sollte auch berücksichtigt werden, wenn man über Bereiche spricht.

Wenn die Schrittgröße nicht Teil dieser Diskussion (oder einer zukünftigen) ist, erscheinen ..= und ..< sehr vernünftig!

Update: Ich denke, ..= und ..< wären eine wirklich gute Lösung. Die Schrittweite als Adapter beizubehalten ist viel sinnvoller.

Sollte diese Diskussion absteigende Bereiche beinhalten? Die aktuelle Lösung zum Invertieren des Bereichs ist ziemlich verwirrend (würde es aber vielleicht nicht tun, wenn wir inklusive Bereiche hätten).

zB Können Sie dies lesen und verstehen, ohne die Augen zusammenzukneifen?

for i in (1..l.len()).rev() { ... }

BEARBEITEN: und mit der Schriftart von GitHub ist es noch verwirrender, da l wie 1 aussieht

Ich denke, eine negative Schrittweite würde ausreichen.

Wir könnten die Matlab-Syntax verwenden, a:b und a:step:b .

Am 4. November 2016 um 00:50 Uhr schrieb "Ott" [email protected] :

Ich denke, eine negative Schrittweite würde ausreichen.

—
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/rust-lang/rust/issues/28237#issuecomment -258344460,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3n3kwnGH6POQb4dGwCwJ8yOGqPSBQks5q6rmDgaJpZM4F4LbW
.

@durka Was wäre also das Äquivalent des aktuellen .. , wo es keine a oder b ? Nur : ?

Etwas, das ich im RFC nicht gesehen habe: Wurden unterschiedliche Namen für die Felder berücksichtigt?

Bei unterschiedlichen Typen kann es sinnvoll sein, unterschiedliche Feldnamen zu verwenden, wenn diese unterschiedliche Bedeutungen haben. Beispielsweise ist "range.start" bei allen Typen "die untere inklusive Grenze". Aber "range.end" ist manchmal inklusiv und manchmal exklusiv. Eine Unterscheidung zwischen „Ende“ und (Strohmann) „letzter“ macht das deutlicher.

(Dies ist natürlich irrelevant, wenn die verschiedenen Typen zugunsten von Range aufgegeben werden>...)

Ich denke, Inclusive Range sollte immer noch std::collections::range::RangeArgument implementieren.

pub trait RangeArgument<T> {
    fn start(&self) -> Option<&T> { ... }
    fn end(&self) -> Option<&T> { ... }
}

Dann

impl RangeArgument<T> for RangeToInclusive<T> {
   fn end(&self) {
     Some(self.end+1)
   }
}

Damit fn foo<T, R: RangeArgument<T>>(arg: R) entweder inklusive oder halboffene Ranges annehmen kann.

@durka Das Problem mit der a:b-Syntax besteht darin, dass sie mit der b oder einem Typ b ? Natürlich schreiben wir als gute Rust-Programmierer unsere Typen groß, aber der Compiler kann das nicht ableiten.

.. Operator mit mathematischen Definitionen (basierend auf @duesee Kommentar):

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

Verwenden (basierend auf @0tt- Beispiel):

fn fizzbuzz_to(n: u32) {
    for n in [1..n + 1] {
        fizzbuzz(n);
    }
}

In diesem Fall verwenden wir .. nur als Hinweis, aber die Grenzen werden durch [ und ]

@adelarsq : In Rust brauchen wir keine Bereiche, die den Start nicht enthalten. Aber die Klammersyntax macht nur Sinn, wenn diese erlaubt sind. Außerdem wird die Klammersyntax bereits verwendet.

Ich denke, ..= ist die vernünftigste Wahl für Inklusivbereiche.
Visuell leicht von .. , was ... nicht ist. Die Wahrscheinlichkeit, ... wenn .. gemeint ist oder umgekehrt und es nicht bemerkt, ist höher als bei ..= .
(Es ist vergleichbar mit der versehentlichen Eingabe von if(a = b) anstelle von if(a == b) in C, sowohl in Bezug auf die visuelle Erkennbarkeit als auch auf das Fehlerpotenzial).
Und ..= ist leicht zu merken, weil es für seine Bedeutung symbolisch ist ( i ..= j bedeutet den Bereich i .. j und wo i = j ).

Es scheint, dass die Hauptbeschwerde darin besteht, dass ... .. zu ähnlich ist. Mir ist aufgefallen, dass sich niemand über die Anzahl der Zeichen beschwert, wenn andere Vorschläge gemacht werden, die mehr Zeichen beinhalten, sondern nur Dinge wie Klammerübereinstimmung und Verwendung an bestimmten Stellen.
Was ist also mit .... für Inklusivbereiche? Es sollte immer noch wie eine Reihe aussehen, und wie gesagt, niemand scheint eine Lösung zu stören, die einen zusätzlichen Charakter braucht. Es ist fraglich, ob es mehr oder weniger wackelig ist als ..= .
for i in 0....10 { println!("just a thought"); }

Wäre das Standardverhalten inklusive der ..! Operator verwendet würde (fast als Negation).

Das Problem mit .... ist, dass es einige Verwirrung geben würde, wenn ... wirklich existiert.

Ich mag ... auch nicht wirklich, da es genau das Gegenteil von Ruby ist .

Die beste Option ist bisher ..= denke ich.

@adelarsq, die .... Betreiber würde die ersetzen ... Operator, wenn Sie also tun versucht , .. extra und hinzugefügt . , wäre es eine Kompilierung sein Zeitfehler, wenn Sie versucht haben, .... auszuführen und einen Punkt vergessen haben, wäre dies ebenfalls ein Fehler.

Da beim Mustervergleich ... verwendet wird, um den inklusiven Bereich abzugleichen, ist es sinnvoll, auch ... für den inklusiven Bereichsausdruck zu verwenden.
Für den Bereich mit Schritt bevorzuge ich die Haskell-Syntax, zB 1,3..9 => [1,3,5,7]

Für Bereiche mit Step/Reverse usw. würde ich eine gute altmodische Funktion (eine Art Range Konstruktor) anstelle eines komplexen Literals bevorzugen.

Ich wäre mit Quad-Dot .... in Ordnung (obwohl ..= IMHO auch in Ordnung ist). Aus Konsistenzgründen könnte es auch beim Mustervergleich erlaubt sein (und schließlich könnten ... in Mustern veraltet sein).

Für mich ist ..= eine visuelle Bedeutung, die .... nicht hat.

Mir ist gerade etwas aufgefallen:

In der Mathematik könnte man ∀ i: 0 ≤ i < 10 schreiben, was übersetzt in

for i in 0 ..< 10 { }

Dies ist konsistent.

Die Aussage ∀ i: 0 ≤ i ≤ 10 würde sich jedoch in

for i in 0 ..= 10 { }

Hier wird ≤ in = übersetzt, was sich inkonsistent anfühlt.

Das mag Fahrradschuppen sein, aber

for x in 0 ..<= 10 { }

fühlt sich richtiger an. Dies kann an meinem C-Hintergrund liegen, wo

for (unsigned int i = 0; i <= 10; ++i) { }

übersetzt in "solange i kleiner oder gleich 10 , etwas tun". In CI sollte == in Schleifenbedingungen verwendet werden, da die Möglichkeit besteht, den Wert zu überspringen und in einer Endlosschleife zu landen. Dies kann in Rust nicht passieren, aber die Übersetzung von for i in 1 ..= 10 in C könnte genau das nahelegen.

Nimm es weiter,

for i in 0 <..<= 10 { }

wäre selbsterklärend.

Bearbeiten: Hier war ein schlechtes umgekehrtes Beispiel, das zeigen soll, wie verwirrend die Verwendung von nur = sein kann. Gelöscht, da es eher verwirrend als konstruktiv war.

@duesee Wie ist >=..> selbsterklärend? Sollte es nicht <=..> (<= 10 und > 0) sein?
IMO ist es nicht selbsterklärend, es ist kryptisch und zu lang als Operator.
(Kein Operator sollte IMO länger als 3 Zeichen sein).
Übrigens, wir haben bereits eine Möglichkeit, die umgekehrte Iterationsrichtung auszudrücken: .rev()
Wir brauchen nur Operatoren für inklusive Bereiche und vielleicht .step_by() .
Für den Schritt könnte die Syntax a .. b | s (und für inklusive Bereiche: a ..= b | s ).

@norru : Ihr Beispiel for i in (1..l.len()).rev() { ... } ist sehr unrealistisch, da Sie die meiste Zeit Slices verwenden würden ( for x in arr[1..].rev() { ... } ), aber selbst wenn Sie gezwungen sind, den Index-Stil der Iteration zu verwenden (im Grunde nur Wenn Sie Array-Elemente ändern, die sich nicht auf i ), fällt es mir überhaupt nicht schwer, es zu lesen. (Aber ich lasse normalerweise Leerzeichen um .. wenn die Argumente keine wörtlichen Zahlen sind: (1 .. arr.len()).rev() )

>=..> mehr Fischarten bei Rust-Betreibern!

Aber ich mag ..<= sehr (edit: ähm, außer in match wo es aussieht wie <= 0 => :()

• Es unterscheidet sich sehr von einfachen .. ,
• es hat nicht die += Konnotation von ..= ,
• es stimmt logischerweise sogar mit Swifts ..< überein. Es ist möglich, dass beide Sprachen konvergieren!
• und vor allem ist es ziemlich klar, dass Sie Zahlen im Bereich erhalten, die kleiner oder gleich der oberen sind.

@pornel : >=..> more species of fish in Rust operators! Hehe :-)

@Boscop : Es ist selbsterklärend, wenn Sie es wie eine Definition in Mathematik lesen: 10 >= i > 2 . Für den Rest Ihrer Antwort: Ich stimme absolut zu. Der zweite Teil war als Motivation gedacht, ..= vs. ..<= zu überdenken, um keine Blocker für zukünftige Erweiterungen einzuführen. Ich werde meine Antwort entsprechend bearbeiten.

kann auch ein Flag erhalten, um bei der .. Notation zu warnen oder zu fehlern

Ich möchte nicht, dass .. irgendwo in meiner Codebasis erscheint

Ich möchte eine weitere Stimme für ..= abgeben

Der Nachteil von ..< und ..<= ist, dass sie bereits gültiger Code sind (ein rechtsoffener exklusiver Bereich wird mit einem anderen Wert verglichen).

@thepowersgang

Der Nachteil von ..< und ..<= ist, dass sie bereits gültiger Code sind (ein rechtsoffener exklusiver Bereich wird mit einem anderen Wert verglichen).

Obwohl dies wahr ist, scheint es ziemlich unwahrscheinlich, dass dies in der Praxis ein Problem darstellt, oder?

Ich bevorzuge ... gegenüber den anderen Vorschlägen hier.. aber wenn ich eine alternative Syntax auswählen müsste, wäre es ..=

@nikomatsakis

Ich bin gegen die Optionen ..< und ..<= allein aus dem Grund, dass sie den Prozess der Aneignung eines intuitiven Modells der Grammatik der Sprache unverhältnismäßig komplizieren.

Persönlich finde ich sie mindestens so hässlich und unelegant wie die Turbofish.

Ich würde .. für rechts-exklusiv und ..= für inklusiv als beste Balance zwischen visueller Eleganz, intuitiv zu verstehenden Grammatikregeln und einer Verwechslungsgefahr wählen.

Ist ... wirklich so ununterscheidbar von .. ? Warum gefällt es mir so gut?

@tshepang

Ich mag ... weil es ästhetisch ansprechend ist... aber ich argumentiere dagegen, weil ich befürchte, dass es das Potenzial hat, schwer zu bemerkende Fehler zu verursachen, ähnlich wie beim Schreiben von if (x = 2) { anstelle von if (x == 2) { in C/C++. (Und es ist bekannt, was für eine Gefahr sich herausstellte.)

@ssokolow

IMO lässt sich das besser durch Linting oder Optionsflags lösen. Ich sehe nicht viel Sinn für das Mischen von Notationen in einer einzelnen Datei/einem Projekt.

Bevorzugen Sie auch .... gegenüber den anderen Optionen. Die doppelte Breite/der doppelte Abstand sollte es offensichtlich genug machen, insbesondere wenn man bedenkt, dass sie auf beiden Seiten von Symbolen flankiert werden, die diesen negativen Raum stärker ausgeprägt als isoliert machen.

@ssokolow

Ich würde mit .. für rechts-exklusiv und ..= für inklusiv als beste Balance zwischen visueller Eleganz, intuitiv verständlichen Grammatikregeln und einer Verwechslungsgefahr gehen.

Für mich geht das. Der wichtigste Knackpunkt ist, ob wir auch für andere Fälle eine Syntax haben wollen (zB <..<= ). Ich persönlich finde, dass .. und ..= etwa 99,5 % der Fälle abdecken. Ich denke, der Hauptanwendungsfall sind APIs wie drain , und wir haben dort derzeit einen eigenen Ansatz verfolgt .

cc @rust-lang/libs

Die ungewöhnlichen Fälle können wir der direkten Konstruktion der Bereiche überlassen mit
struct-Literale.

Am Mittwoch, 22. Februar 2017 um 16:50 Uhr, Niko Matsakis [email protected]
schrieb:

@ssokolow https://github.com/ssokolow

Ich würde mit .. für rechts-exklusiv und ..= für inklusive am besten gehen
Balance zwischen visueller Eleganz, Grammatikregeln, die einfach bis intuitiv sind
erfassen und die beiden schwer zu verwechseln.

Für mich geht das. Der wichtigste Knackpunkt ist, ob wir auch eine
Syntax für andere Fälle (zB <..<=). Ich persönlich empfinde das .. und ..=
deckt etwa 99,5 % der Fälle ab. Ich denke, der Hauptanwendungsfall sind APIs wie Drain,
und da haben wir aktuell einen klaren Weg eingeschlagen
https://doc.rust-lang.org/std/collections/struct.BTreeMap.html#method.range
.

cc @rust-lang/libs https://github.com/orgs/rust-lang/teams/libs

—
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/rust-lang/rust/issues/28237#issuecomment-281815665 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3n-aKwYKFq4VI9RizL0GkzXXSjTPwks5rfK2ngaJpZM4F4LbW
.

Ich nehme an ..= wird es auch in Mustern geben? Was wird dort aus der bestehenden ... Syntax?

Es kann verworfen werden. Aber seine Existenz ist ein ziemlich starker Präzedenzfall für
zumindest als Kurzform verwenden.

Am Mittwoch, den 22. Februar 2017 um 18:02 Uhr schrieb andrewtj [email protected] :

Ich nehme an ..= wird es auch in Mustern geben? Was wird aus
die vorhandene ... Syntax da?

—
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/rust-lang/rust/issues/28237#issuecomment-281834007 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3nw_DaOMNxuIKw6ZFfXJW95QyijY4ks5rfL6DgaJpZM4F4LbW
.

@durka @andrewtj Ich würde davon ausgehen, dass wir es

..= kann als Operator im Sinne von += .
Ich schlage vor, Gezeiten ~ , zB 0~9 , 'A'~'Z' .

Welcher Operation würde ..= entsprechen? - ist offensichtlich unrentabel, weil
1-9 == -8 .

Am Mittwoch, 22. Februar 2017 um 20:04 Uhr, Junfeng Liu [email protected]
schrieb:

..= kann als Operator im Sinne von += verwendet werden.
Ich schlage vor, ~ zu verwenden, zB 0~9, 'A'~'Z'.

—
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/rust-lang/rust/issues/28237#issuecomment-281856846 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3n7N2dM4DAzc_uc5JdHit4IJgyvYGks5rfNsPgaJpZM4F4LbW
.

@durka ..= nur aus wie Zuweisungsoperatoren, der Anwendungsfall muss selten sein. ~ ist Gezeiten nicht unter. Verwenden Sie ... ist auch in Ordnung.

impl Fill for Range<String> {
   fn fill() -> String { ... }
}
impl FillAsign for RangeAssign<String> {
   fn fill(&mut self) { ... }
}
(String::new("abc") .. String::new("f")).fill()  // "abcdef"
(String::new("abc") ..= String::new("f")).fill()  //  ()

Entschuldigung, in meiner Schriftart sieht es genauso aus. Ich habe gefragt, ob ..= eine Verbindung ist
Zuweisungsoperator wie +=, welche Operation führt er aus (entsprechend
zu +)?

Am Mittwoch, 22. Februar 2017 um 20:29 Uhr, Junfeng Liu [email protected]
schrieb:

@durka https://github.com/durka ..= einfach wie Aufgabe aussehen
Operatoren muss der Anwendungsfall selten sein. ~ ist Gezeiten nicht unter.

impl Füllen für Bereich{
fn fill() -> String { ... }
}
impl FillAsign für RangeAssign{
fn fill(&mut self) { ... }
}
(String::new("abc") .. String::new("f")).fill() // "abcdef"
(String::new("abc") ..= String::new("f")).fill() // ()

—
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/rust-lang/rust/issues/28237#issuecomment-281861478 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3n39uqbADB1rNtBh3PBTRY2XBXOUNks5rfOD-gaJpZM4F4LbW
.

@durka @nikomatsakis Okay, ich hoffe, das wird bald gelöst. Die aktuelle Situation ist unangenehm und die Änderung der Syntax wird es auch sein.

@pornel Die Einstellung von ... in match würde die Kompatibilität beeinträchtigen , daher ist dies keine gute Lösung. Ich finde ... am angemessensten (allerdings ist es eine genaue Umkehrung von Ruby, aber Rubyisten diskutieren kein ähnliches Problem).

@hyst329 aber ... kann anfälliger für Fehler sein, da das Fehlen oder Hinzufügen eines . eine neue Bedeutung gibt

Abwertung macht nichts kaputt. Die alte Syntax muss für bestehende Programme für immer unterstützt werden, aber Benutzer können über Dokumentation und rustfmt auf die neue Syntax gelenkt werden.

Benutzer können jedoch über Dokumentation und rustfmt auf die neue Syntax gelenkt werden.

Ich rate dringend davon ab, dafür rustfmt zu verwenden. Es würde die fußwaffenähnlichen Eigenschaften von ... verschlimmern, wenn es im Modus "Änderungen automatisch anwenden" verwendet wird, da es Tippfehler im Stillen in Dinge übersetzen könnte, die viel zielgerichteter aussehen. (Dadurch werden sie bei der späteren Untersuchung leichter übersehen.)

Eine Compiler-Warnung im Sinne von "Bitte überprüfen Sie, was Sie gemeint haben und verwenden Sie entweder .. oder ..= ", die nicht automatisch korrigiert werden kann, würde viel eher den bestehenden Bemühungen entsprechen, die Chance für menschliches Versagen.

Bitte beachten Sie, dass ich im Zusammenhang mit den vorhandenen ... in Mustern gesprochen habe, in denen keine Schusswaffe existiert. Derzeit befindet sich Rust in einer zeitweiligen Situation ohne Schusswaffen, in der Muster nur ... und Ausdrücke nur .. zulassen, sodass beide vor Tippfehlern geschützt sind.

Natürlich würde ich nicht empfehlen, ... in Ausdrücken in ..= umzuwandeln, da dies natürlich nur den Tippfehler dauerhaft machen würde.

Ahh. Das hatte ich vergessen. Danke, dass du mich erinnert hast.

@adelarsq Eigentlich lassen sich gängige Fehler wie 'a'..'z' oder 128u8..255u8 einfach als Warnungen in cargo-clippy integrieren. Und auch die Breite von .. und ... sich deutlich (bei Verwendung von Monospace-Schriftarten natürlich; sie nicht zu verwenden ist normalerweise eine schlechte Idee, um Quellcode im Allgemeinen zu schreiben - nicht nur für Rust). .

Wir könnten die Syntax dafür einfach … (unicode horizontale Ellipsen) anstelle von ... diese Weise würde es zumindest niemand aus Versehen eingeben.

Bearbeiten: Oh, niemand hat diesen Vorschlag ernst genommen :cry: Entschuldigung für den Lärm.

Ich weiß nicht, zuletzt habe ich nachgesehen, dass Google Docs automatisch konvertiert ... in Auslassungszeichen. Hauptakteur in der Textbearbeitungsbranche.

Außerdem hat nicht jeder eine Compose- Taste, um bequem Compose einzugeben . . wenn sie wollen …

Unter Windows kann ich Ellipsen mit Alt + 0133 mit dem Nummernblock eingeben! …

Und ähnliche Codepunkt-basierte Mechanismen existieren auf verschiedenen Ebenen des Stapels auf X11-basierten Desktops (ich erinnere mich, dass GTK+ und der X11-Eingabestapel ihre eigenen unabhängigen Lösungen haben), aber es ist ein großer Aufwand, sich Codepunkte nach Nummer zu merken.

Compose ist eine intuitive Lösung.

Die einzige Windows- Alt- Sequenz, an die ich mich erinnere, ist Alt + 219 aus allen DOS-Batch-Dateimenüs, die ich als Kind erstellt habe.

Die aktuelle Syntax existiert schon seit langer Zeit, lasst uns sie einfach schon stabilisieren und dieses endlose Bikeshedding stoppen.

Die Beibehaltung der aktuellen Syntax ist das Schlimmste, was wir tun können, da sie viele echte Nachteile hat. Dies ist nicht nur Fahrradabwurf – es sollte richtig gemacht werden. Den ganzen Thread überspringend, wurde die Syntax ..= am meisten akzeptiert...

Ich fühle mich im Moment ein bisschen so, als würde es ein totes Pferd schlagen, aber wenn du darüber nachdenkst... Der Unterschied zwischen .. und ... ist buchstäblich eine Kopie des kleinstmöglichen Charakters, den du hast kann tippen oder lesen, gemischt mit einer Gruppe identischer Zeichen und hat das Potenzial, eine extrem häufige und oft irritierend schwer zu findende Fehlerklasse (Off-by-One-Fehler) in Fällen zu erzeugen, die ansonsten völlig nicht zu unterscheiden sind zu Mensch und Maschine.

Oder wir könnten buchstäblich jede andere Syntax der Welt verwenden.

Einerseits weiß ich diese Bedenken zu schätzen. Andererseits ist die aktuelle ... Mustervergleichssyntax bereits enthalten, was sie perfekt mit der Syntax konsistent macht, die bereits an anderer Stelle in Rust verwendet wird.

Und ich persönlich habe keine Probleme, den Unterschied zu erkennen, obwohl ich erkenne, dass Menschen mit Sehproblemen oder mit einem 4K-Monitor und einer 10pt-Schriftart dies möglicherweise tun.

Aber es scheint, als ob der Konsens bei ..= herrscht und ich denke, auch damit bin ich einverstanden.

FWIW, ich hatte diese Situation, in der ich versehentlich ... getippt habe, als ich .. meinte, und dann eine Weile nicht bemerkte, aber nach einer Weile fragte ich mich, warum sich mein Programm seltsam verhielt.
Also ja, es sollte einen sichtbareren Unterschied geben und ..= macht am meisten Sinn.

Nominierung für @rust-lang/lang Diskussion. Ich denke, wir sollten einfach ..= adoptieren und Schluss machen. Brauchen wir einen geänderten RFC? TU es einfach? Bedeutet dies, dass die vorhandene ... Syntax in Mustern veraltet ist? (Ich gehe davon aus.)

Ich bin nachdrücklich dafür, ... für Bereiche zu verwenden. Ich weiß nicht, ob es in diesem Thread oder im RFC-Thread bereits erwähnt wurde, aber zusätzlich zu der ... , dass .. unangemessen ähnlich sieht, möchten wir vielleicht auch ... in Zukunft für variadische Generika, die viel wichtiger sind als Inklusivsortimente IMO.

..= scheint klar und seine relative Hässlichkeit wird dadurch gerechtfertigt, dass es weniger verbreitet ist als .. .

Bedeutet dies, dass die vorhandene ... Syntax in Mustern veraltet ist? (Ich gehe davon aus.)

Dies scheint eine gute Idee zu sein. Warnen Sie bei ... und unterstützen Sie sowohl .. als auch ..= in Mustern, wenn wir können.

Ich bin im Allgemeinen vorsichtig mit der Einführung von Warnungen, die so viele Leute betreffen würden, ohne auch ein automatisiertes Tool zum Aktualisieren der Syntax zu haben, aber ... in ..= ist eine besonders einfache Änderung. Wir könnten die Warnung auch ablehnen, aber verschieben, bis wir ein solches Tool haben. Was denken alle anderen?

Ich befürworte nachdrücklich ... da es sich um eine "üblichere" Syntax handelt; Ich kenne keine Sprache, die ..= , aber viele, die .. und ... .

Wenn die Stimmung gegen ..= stark ist, würde ich es vorziehen, keine inklusive Bereichssyntax zu verwenden (anstatt sich für eine (a..b).inclusive() Methode zu entscheiden, die mir prägnant genug erscheint), um das visuelle Problem zu vermeiden und wieder frei bis ... für variadische Generika.

BEARBEITEN: Ein gutes Argument gegen (a..b).inclusive() ist, dass wir immer noch ... in match und leider keine neue Syntax, durch die es ersetzt werden könnte. :verwirrt:

@steveklabnik Entschuldigung, wenn dies bereits irgendwo in diesem (sehr langen) Thread erwähnt wird, aber: Welche anderen Sprachen verwenden sowohl .. als auch ... für exklusive bzw. inklusive Bereiche?

Rust hat in der Vergangenheit nützliche Funktionen und Syntax aus anderen Sprachen übernommen, jedoch selektiv und gegebenenfalls abgelehnt oder angepasst.

@joshtriplett Ruby verwendet beide, aber mit entgegengesetzten Bedeutungen ( .. ist inklusive, ... ist exklusiv). Ich glaube nicht, dass es in Ruby eine gute Idee war, und es scheint für uns noch verwirrender zu sein, beides zu haben, aber umgekehrt.

@joshtriplett, mit dem ich am besten vertraut bin, ist Ruby; Ich dachte, es kommt von Perl, bin mir aber nicht ganz sicher. Ich bin damit einverstanden, dass die Semantik von Ruby rückwärts ist, als mit ..= .

Ehrlich gesagt würde ich eine stabile inklusive Bereichssyntax allem anderen vorziehen und erkenne an, dass meine starke Abneigung gegen ..= eine persönliche Sache ist, bei der vernünftige Leute anderer Meinung sind.

@steveklabnik Swift verwendet ..< , denke ich, oder? Das scheint ..= ähnlich zu sein, aber noch schlimmer, da es für (imo) den falschen Fall optimiert. =)

Swift verwendet ..< für exklusiv und ... für inklusive (ihre Begriffe sind
"halboffen" und "geschlossen").

Ich mag immer noch ..< (mit .. als Kürzel) und ..=.

Aber eine andere offene Frage (vielleicht nicht in den Bereich dieses Tracking-Problems) ist, ob wir "nur" eine Syntax für geschlossene Bereiche übernehmen oder auch Syntaxen (Syntaxen?) für Bereiche mit dem ersten offenen Punkt, dh Strohmann >..> und >..=.

Am Donnerstag, 16. März 2017 um 14:19 Uhr, Niko Matsakis [email protected]
schrieb:

@steveklabnik https://github.com/steveklabnik Swift verwendet ..<, denke ich,
Rechts? Was ..= ähnlich scheint, aber noch schlimmer, da es optimiert für
(imo) der falsche Fall. =)

—
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/rust-lang/rust/issues/28237#issuecomment-287147321 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3n0Wop5fJh9HVo7pSqo0riHm96Gm4ks5rmX1BgaJpZM4F4LbW
.

Ich hätte nichts dagegen, eine inclusive Funktion im Auftakt zu haben:

for x in inclusive(1..10) {

}

Ich habe nie das Gefühl gehabt, dass Symmetrie mit Streichholz ein zwingendes Argument ist. Ich denke, wir haben beschlossen, exklusive .. Muster hinzuzufügen, aber ich mag diese auch nicht - ein Wert im Muster wird jetzt nicht mit dem Muster übereinstimmen! Das Abgleichen eines Bereichs unterscheidet sich grundlegend vom Durchlaufen eines Bereichs, es gibt keinen Grund, warum sie symmetrisch sein müssen. Ich hätte eine leichte Vorliebe, .. in Mustern nicht zuzulassen, wenn dies immer noch eine Option ist, aber ich denke, das ist nicht so?

Ich glaube, dass die Nachteile mit ..= und ... beide signifikant sind - ..= ist ziemlich seltsam, aber ... erhöht die Wahrscheinlichkeit von Ausfällen um 1 Fehler.

Es ist besser, einen seltsam aussehenden Operator zu haben, als ein so endloses Potenzial für Fehler (jede Sprache führt Operatoren ein, die andere nicht haben, zB ..< in Swift, alle Operationen in F# und Scala). Die Leute werden das Rust-Buch sowieso lesen müssen.
Wenn man bedenkt, dass viele Leute von Ruby zu Rust kommen, sollten wir es im Vergleich zu Ruby nicht rückständig machen. (Zusätzlich zu dem Argument, dass ... die Wahrscheinlichkeit von Fehlern um 1 erhöht.)
Wie können Sie ..< in Swift akzeptieren, aber nicht ..= in Rust? ..= ist nicht so seltsam.

Die Erweiterung der Bereichssyntax in Mustern ist ebenfalls noch eine offene Frage AFAIK.
Zum einen können wir es nicht vollständig tun, weil Enum::Variant(..) bereits ist
gültig und ändert es so, dass Enum::Variant(RangeFull) brechen würde.

Am Donnerstag, 16. März 2017 um 15:07 Uhr schrieb Boscop [email protected] :

Es ist besser, einen seltsam aussehenden Operator zu haben (jede Sprache führt ein
Operatoren, die andere nicht haben, zB ..< in Swift, alle Ops in F#
und Scala). Die Leute werden das Rust-Buch sowieso lesen müssen.
Wenn man bedenkt, dass viele Leute von Ruby nach Rust kommen, haben wir
sollte es nicht rückwärts im Vergleich zu Ruby haben. (Zusätzlich zum Argument
dass ... die Wahrscheinlichkeit von Aus-Fehlern um 1 erhöht.)
Wie können Sie ..< in Swift akzeptieren, aber nicht ..= in Rust?

—
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/rust-lang/rust/issues/28237#issuecomment-287160485 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3nz9ZNR2utl7LPTVvQPQ_Ma8sDBGuks5rmYhmgaJpZM4F4LbW
.

So. Ich möchte in der Lage sein, Sachen wie slice.get(10...30) zu tippen und meinen Kuchen auch zu essen.

Ich habe mich selbst davon überzeugt, dass ich inclusive(0..10) allen anderen Syntaxen vorziehe:

• Während @nagisa slice.get(10...30) schreiben möchte, möchte ich nicht genau darauf achten müssen, ob das slice.get(10...30) oder slice.get(10..30) . Ich denke, die Nähe der Syntax ist ein echtes Problem.
• Ich denke, alle sind sich einig, dass ..= unästhetisch und wahrscheinlich nicht intuitiv ist.
• (0..10).inclusive() hat dieselbe Syntax, ist aber weniger praktisch. Technisch würde inclusive prelude wahrscheinlich beide Syntaxen unterstützen.

Ich denke, es würde so aussehen:

trait IntoInclusive {
    type Inclusive;
    fn inclusive(self) -> Self::Inclusive;
}

fn inclusive<T: IntoInclusive>(range: T) -> T::IntoInclusive {
    range.inclusive()
}

Ich denke, alle sind sich einig ..= ist unästhetisch und wahrscheinlich nicht intuitiv.

Ich denke, das zu sagen, ist ein bisschen zu stark verallgemeinert. Ich finde ..= ästhetischer und intuitiver als eine Methode wie inclusive() .

(Außerdem wissen wir nicht, inwieweit die Abneigung gegen ..= unterbewusste (oder bewusste) Bemühungen sein könnte, Probleme mit Dingen zu finden, die nicht ... .)

.inclusive() ist zu lang für etwas, das so häufig vorkommt (in diesem Sinne denke ich auch, dass es eine kürzere Form für .enumerate() ).
Aber selbst wenn wir .inclusive() , sollte es nur eine Funktion geben, nicht zwei.
Darüber hinaus würden sie nicht in match verwendet werden, wenn sie keine einschließende Bereichssyntax haben.
Aber vielleicht brauchen wir eine Möglichkeit, Extraktoren allgemein anzugeben, wie in Scala ? Damit jeder Typ in einem Match verwendet werden kann, ruft dieses Match implizit seine Methode unapply .

(Außerdem wissen wir nicht, inwieweit die Abneigung gegen ..= unbewusste (oder bewusste) Bemühungen sein könnte, Probleme mit Dingen zu finden, die nicht .... sind.)

Keine von mir. Das ist so etwas wie ein Vorwurf der Bösgläubigkeit.

Darüber hinaus würden sie nicht in Übereinstimmung verwendet werden, wenn sie keine einschließende Bereichssyntax haben.

Inklusive Bereichsmuster werden bereits in match . Tatsächlich sind sie die einzige Art von Sortiment, die wir heute als Muster unterstützen.

@ withoutboats ja, aber ich sagte: " .inclusive() weil sie nicht im Match verwendet werden konnte, es sei denn, wir hätten Extraktoren wie Scala. und der springende Punkt dieses Problems ist, dass die Syntax für den inklusiven Bereich kein Sonderfall sein sollte, der nur in Übereinstimmung funktioniert und um zu bestimmen, wie die Syntax anstelle der aktuellen sein sollte.

Inklusive: for i in 1..10! { }

Als jemand, der mehr als 15 Jahre mit Java/C/C++ arbeitet, finde ich, dass .. vs. ... ziemlich verwirrend ist und schon durch Eingabefehler Fehler verursachen kann. Auch die Beziehung zu Ruby macht dies noch verwirrender. Deshalb ist ..= oder jede andere Alternative besser.

Ich werfe meinen 'Hut' in den Ring:

for i in 1..10^

Der Hut/der Caret symbolisiert, dass der richtige Wert bis ganz nach oben geht.

@leebenson Persönlich

for i in 1..^10

@retep998 Ich geklickt habe ... das ist wahrscheinlich tatsächlich schöner.

@retep998 Dein Vorschlag von ..^ gefällt mir viel besser als ..= ; es scheint seine Bedeutung viel evokativer zu sein und vermeidet es, wie eine seltsame Variante eines erweiterten Zuweisungsoperators auszusehen (wie += und *= ). Das heißt, beides wäre viel besser als ... .

Ich komme nicht hinter ..^ .

Persönlich finde ich es sehr hässlich (teilweise weil .. ^ in vielen Schriftarten so vertikal von

Als UI/UX-Typ denke ich, dass dies ein Beispiel dafür ist, zu schlau für Ihr eigenes Wohl zu sein.

Wenn ich aus einer anderen Sprache komme und ..^ sehe, erkenne ich es möglicherweise nicht einmal als Bereich (soweit ich weiß, könnte 5..^15 eine seltsame partielle faktorielle Abkürzung für 15! - 4! ), weil Menschen in Kontexten denken und die einzige Assoziation, die ein Charakter in einem Mainstream-Programmierkontext hat, die Potenzierung ist.

(Wenn wir nicht in Kontexten dachten, könnte ... so etwas bedeuten wie "Rückruf wird hier eingefügt" oder "Ereignis ausgeben" in Analogie zu seiner "Inhalt weggelassen"-ähnlichen Bedeutung im Dialog in der Prosaschrift, nur um Zeigen Sie das unmittelbarste Beispiel. Ihm eine "geht ganz nach oben"-Bedeutung durch die Ähnlichkeit mit einem Pfeil zu geben, ist wie das Ausführen von Zaubertricks durch Taschenspielertrick, soweit es mit den Erwartungen eines Neulings interagiert.)

Im Gegensatz dazu hat = einen Präzedenzfall dafür, sich sowohl auf die Aktion der Zuweisung als auch auf das Konzept der Gleichheit zu beziehen, und es gibt kein "seltsames Exponentiationssyntax"-ähnliches Missverständnis für ..= da Sie "am nächsten an " Zuweisung + Gleichheit", die nicht bereits vom Zuweisungsoperator behandelt wird, hat "etwas mit einer Zahlenfolge zu tun, die auf der rechten Seite endet" ... was eine vage, aber angemessene Definition der Bereichssyntax ist.

Ich mache mir auch Sorgen, dass, selbst wenn ich aufgrund der Verwendung im Kontext erkennen würde, dass ..^ eine Bereichssyntax ist, ich zunächst keine intuitive Vorstellung davon hätte, ob sie einschließend oder ausschließend war, da ^ keine Bedeutung hat 2..^8 eine Abkürzung für eine offene Range ist, die bei zwei beginnt und den vorherigen Schritt hoch 8 macht (dh 2..Inf^8 im Gegensatz zu 2..+8 ist die Abkürzung für "iterate von 2 bis unendlich in 8er Schritten".)

Dieses Problem wird auch von ..= vermieden, da die Leute es gewohnt sind, in < (exklusiv) vs. <= (inklusive) zu denken, wenn sie while Schleifen schreiben und for Schleifen im C-Stil.

@ssokolow legitime Analyse.

Persönlich kann ich entweder hinter ..= oder ..^ zurückbleiben. Die Symbolik von entweder ist für mich sinnvoll - dh 'bis und gleich' bzw. einfach 'bis'. Beides bedeutet meiner Meinung nach dasselbe.

Es wird schwierig sein, etwas zu finden, das alle zufriedenstellt, weil wir alle Geschichte aus anderen Sprachen mitbringen und damit verdorbene Symbolik / Voreingenommenheit. Ich habe anfangs das ^ Zeichen _nach_ der Zahl hinzugefügt, zum Beispiel, weil das Einfügen vor das Gefühl hatte, einen 'Schritt' oder einen Exponenten darzustellen, während ein Suffix den Bereich unberührt ließ und ein irgendwie reineres Gefühl hatte. Aber das bin nur ich.

Auf jeden Fall würde ich eine Kurzschreibweise in irgendeiner Form gegenüber einem Funktionsaufruf bevorzugen, der implizit dem rechten Wert +1 gibt. Ich stimme früheren Kommentaren zu, dass dies eine zu häufige Syntax ist, um sie an etwas zu delegieren, das sich wie ein Funktionsaufruf anfühlt. Ich hätte sogar nichts dagegen, ... , aber zugegeben, es ist wahrscheinlich der = / == Bug in neuer Kleidung und wird bestimmt jemandem in den Fuß schießen...

viele Leute scheinen aktiv nicht zu mögen ..= niemand hat etwas Negatives gesagt
über .... es wurde nur stillschweigend ignoriert (bis auf ein paar Daumen hoch) I
Ich dachte, ich würde es noch einmal zur Sprache bringen und die Leute dazu bringen, es zu betrachten und zu geben
Grund für die Nichtverwendung, wenn sie dagegen sind.

Ich hasse es, es überhaupt zu erwähnen, weil es nur mehr Lärm ist, aber was ist mit .:
(Punkt Doppelpunkt) für inklusive? Es sind 3 Punkte, aber 2 Zeichen, und ich denke, die
Form unterscheidet es von ..

Am Samstag, 18. März 2017 um 11:50 Uhr, Lee Benson [email protected]
schrieb:

@ssokolow https://github.com/ssokolow legitime Analyse.

Persönlich kann ich entweder hinter ..= oder ..^ stehen. Die Symbolik von entweder
macht für mich Sinn - also 'bis und gleich' oder einfach 'bis',
bzw. Beides bedeutet meiner Meinung nach dasselbe.

Es wird schwer sein, etwas zu finden, das alle zufriedenstellt,
weil wir alle Geschichte aus anderen Sprachen mitbringen und damit verdorben
Symbolik/Voreingenommenheit. Ich habe anfangs das ^-Zeichen nach der Zahl hinzugefügt, für
B. weil das Einfügen vorher das Gefühl hatte, einen 'Schritt' darzustellen
oder Exponent, während ein Suffix den Bereich unbefleckt und irgendwie reiner ließ
Gefühl. Aber das bin nur ich.

Auf jeden Fall würde ich eine Kurzschreibweise in irgendeiner Form gegenüber a . bevorzugen
Funktionsaufruf, der implizit dem rechten Wert +1 gibt. Ich stimme früher zu
kommentiert, dass dies eine zu häufige Syntax ist, um sie an etwas zu delegieren
fühlt sich an wie ein Funktionsaufruf. Ich hätte sogar nichts dagegen ..., aber zugegeben, es ist
wahrscheinlich der = / == Käfer in neuer Kleidung und gezwungen, jemanden in die zu erschießen
Fuß...

—
Sie erhalten dies, weil Sie einen Kommentar abgegeben haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/rust-lang/rust/issues/28237#issuecomment-287566556 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AIhJ6jWgPwndKaQvVjULlV_OoC6WDO0Cks5rnCeLgaJpZM4F4LbW
.

Oh, ist das noch in einer Fahrradschuppen-Phase? 😆

Beim Zurücklesen denke ich, dass ich ..= und es zu beenden . Die Ähnlichkeit von .. vs ... ist zu subtil, und ich würde lieber sehen, dass das ... Token ohne Mehrdeutigkeit für variadische Generika verwendet wird (https://github.com/ rust-lang/rfcs/pull/1935), wo es einen ganz bestimmten Zweck erfüllt, der zu weniger Verwirrung zwischen den beiden führen sollte.

Ich bin mir nicht sicher, ob der Wunsch nach einer allgemeineren Syntax für alle halboffenen Varianten noch vorhanden ist, aber ich denke, es lohnt sich nicht, eine Sprachsyntax außerhalb von .. und ..= bereitzustellen .

Ich hasse es, es überhaupt zu erwähnen, weil es nur mehr Lärm ist, aber was ist mit .: (Punkt Doppelpunkt) für inklusive?

Ich denke, @ssokolow hat einige großartige Punkte in

Ich persönlich habe _null_ Einwände dagegen, dass es einen dritten Punkt gibt, außer zu wissen, dass er irgendwann einige Leute zum Stolpern bringen wird. Aber es ist auch kinderleicht zu erklären, daher bin ich mir nicht sicher, ob die Sprache dafür verantwortlich sein sollte, clevere Problemumgehungen zu entwickeln. Ist '2 Punkte exklusiv; 3 Punkte inklusive' wirklich _das_ schwer zu verstehen/zu debuggen?

Auf jeden Fall – wer trifft die endgültige Entscheidung und was ist der nächste Schritt, um dies abzuschließen? 18 Monate Diskussion über den dritten Charakter, wahrscheinlich _ist_ zu diesem Zeitpunkt bikeshedding 😄

Zugegeben, ^ lässt es wie einen Schritt aussehen.
IMO ist die Inkonsistenz mit anderen op= Operatoren kein Problem, da wir niemals a ..= b im Sinne von a = a .. b , da .. ist kein Operator, sondern syntaktischer Zucker, um einen Range zu konstruieren (und wir haben kein allgemeines Op-Überladungsschema, bei dem jeder Op automatisch die Form op= und .. erhält).
Ich sage nicht, dass ..= klar ist, ohne in das Dokument zu schauen. Aber wenn die Leute sich das Dokument einmal angesehen haben, ist es einfacher auswendig zu lernen, und sie müssen sich das Dokument sowieso ansehen.

Angesichts der Nominierung von @nikomatsakis denke ich, dass wir dies im Lang-Team-Meeting nächste Woche diskutieren und wahrscheinlich zu diesem Zeitpunkt einen Anruf

Ich mache mir auch Sorgen, dass, selbst wenn ich aufgrund der Verwendung im Kontext erkennen würde, dass ..^ eine Bereichssyntax ist, ich zunächst keine intuitive Ahnung hätte, ob sie einschließend oder ausschließend ist

Einverstanden. Tatsächlich habe ich diese Syntax bereits in Perl 6 gesehen, wo sie exklusiv bedeutet, das Gegenteil des Vorschlags hier.

@solson Das ist ein sehr überzeugendes Argument dagegen.

Perl scheint eine völlig allgemeine Syntax zu haben, mit .. Bedeutung inklusive (auf beiden
Seiten) und ^ auf beiden Seiten macht diese Grenze exklusiv.

Am Samstag, 18. März 2017 um 18:51 Uhr, Josh Triplett [email protected]
schrieb:

@solson https://github.com/solson Das ist ein sehr überzeugendes Argument
dagegen.

—
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/rust-lang/rust/issues/28237#issuecomment-287580739 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3n7Fnn1_t9BkYOhfS-7oCaGlVff2aks5rnF_5gaJpZM4F4LbW
.

Es tut mir leid zu sagen, aber als wir dieses Thema im @rust-lang/lang-Meeting diskutierten, konnten wir keinen Konsens erzielen. Insbesondere @Withoutboats hat einige starke Vorbehalte, die sie hoffentlich für sich selbst lüften können.

Einige wichtige Punkte, die wir besprochen haben:

• Wenn wir in Ausdrücken und Mustern eine inklusive Bereichssyntax haben, sollte sie gleich sein
  
  
  
  • dh, wenn wir x ..= y , bedeutet dies, dass die vorhandene x...y Mustersyntax veraltet ist.
  
  
• Eine verlockende Option ist, "nichts zu tun" und einfach (x..y).inclusive() oder so etwas zu schreiben. Dies funktioniert jedoch nicht in Mustern (die vermutlich bei x...y bleiben würden). Dies wirft einige eigene Fragen auf:
  
  
  
  • Wollen wir noch exklusive Sortimentsmuster ? zB match 3 { 1..3 => false, .. }
    
    
    
    
    
    • Wenn ja, dann haben wir die gleiche potenzielle Verwirrung!
    
    
    
  
  
  • @Withoutboats scheint zu denken, dass wir solche Muster vielleicht nicht wollen. Ich und @joshtriplett waren absolut notwendig . =)
  
  
• Ein weiteres Problem bei exklusiven Bereichsmustern besteht darin, dass sie schlecht mit den (ebenfalls instabilen) Slice-Mustern interagieren (siehe https://github.com/rust-lang/rust/issues/23121 für Details).

Ich denke , aus dieser Diskussion ging hervor , dass es gut wäre , über alle widersprüchlichen Faktoren auf einmal eine Entscheidung zu treffen . Mit anderen Worten, um eine Entscheidung zu treffen, die Folgendes regelt:

• Was über exklusive Auswahl Ausdrücke zu tun?
• Müssen wir die bestehenden exklusiven Sortimentsmuster ablehnen/ändern?
• Was tun bei inklusiven Bereichsmustern ?
• Was tun bei Slice-Mustern ?

Bevor ich mit diesem Aufschreiben beginne, möchte ich sagen, dass ich mich sehr unsicher fühlte, ob wir in jedem Moment des Gesprächs tatsächlich über das gleiche Konzept sprachen. Niko sagt zum Beispiel, dass "exklusive Bereichsmuster irrelevant erscheinen, bis Sie sie wollen", aber ich dachte, Niko und Josh sprachen zu dieser Zeit über inklusive Bereichsausdrücke.

(Und ich denke, im letzten Teil von Nikos Post sollte der erste Aufzählungspunkt, der derzeit "exklusive Reichweitenausdrücke" lautet, "inklusive Reichweitenausdrücke" heißen.)

TL;DR meine Meinung

Über Bereichsausdrücke:

• Wir sollten keine Syntax für inklusive Bereichsausdrücke einführen - weder ... noch ..= .
• Wir sollten dem Auftakt eine Funktion hinzufügen, die einen exklusiven Bereichswert annimmt und einen inklusiven Bereichswert zurückgibt. Sie würden also inclusive(0..10) schreiben (der Name kann mit dem Fahrrad verworfen werden).

Über Bereichsmuster:

• Wir sollten keine exklusiven Sortimentsmuster einführen oder auf irgendeine Weise eines erstellen.

Mit anderen Worten, die einzige wesentliche Änderung, die wir vornehmen sollten, ist eine Libs-Änderung: Fügen Sie dem Präludium eine Funktion hinzu.

Bereichsausdrücke

Grundlegend für mein Argument ist die Tatsache, dass das Durchlaufen eines einschließenden Bereichswerts eine ungewöhnliche Notwendigkeit ist. Ich denke, dies wird durch die Tatsache bestätigt, dass wir dieses Feature trotz der Annahme des RFC vor 18 Monaten immer noch nicht stabilisiert haben - nicht wegen Implementierungsproblemen, sondern weil wir mit dem Kompromiss nicht zufrieden sind.

Ich denke, inklusive Bereichsausdrücke werden oft genug benötigt, um eine einfache Methode zu ihrer Erstellung zu unterstützen, aber nicht oft genug, um die Nachteile der bisher besprochenen Syntaxen zu überwinden.

Ein Nachteil aller syntaktischen Lösungen ist insbesondere, dass keine von ihnen wirklich selbstdokumentierend ist. Es ist relativ nicht offensichtlich, dass 0...10 oder 0..=10 ein inklusiver Bereichsausdruck ist. Da sie relativ selten anzutreffen sind, wird dies ein Stolperstein für Benutzer sein, die ihnen zum ersten Mal begegnen.

Das heißt, wenn der Benutzer überhaupt merkt, dass er es nicht mit einem "normalen" .. Bereich zu tun hat. Natürlich ist dies das große Problem bei ... , aber ..= beseitigt das Problem nicht = Zeichen (oder ^ oder : oder was auch immer) zu übersehen. Nicht so einfach wie die zusätzlichen . , aber ich bin nicht davon überzeugt, dass es auffällig genug ist.

Ich denke tatsächlich, dass es zwischen ... und ..= einen Kompromiss zwischen "Erkennbarkeit vs. Offensichtlichkeit" gibt. Ich denke, es ist offensichtlicher, was ... bedeutet (es sei denn, Sie kommen von Ruby, wo die beiden Syntaxen die entgegengesetzte Bedeutung haben) als ..= , aber es ist definitiv weniger auffällig .

Aber ich denke, eine Präludiumsfunktion wie inclusive(0..10) ist sowohl offensichtlicher als auch auffälliger als jede Syntax, die wir besprochen haben. Ja, es müssen mehr Zeichen eingegeben werden, aber der Nachteil dieses Attributs hängt von der Häufigkeit der Verwendung ab.

Es umgeht auch alle Parsing- und Tokenisierungsprobleme und hilft Benutzern bei dem (sehr nervigen) Problem mit der Rangfolge gegenüber der Methode, bei dem sie (0..10).filter und dergleichen schreiben müssen.

Reichweitenmuster

Der Hauptgrund, warum wir .. nicht hinzufügen sollten, ist, dass es Mehrdeutigkeiten bei Slice-Mustern einführt, was meiner Meinung nach nützlich ist. Ich möchte dieses Problem lösen, indem ich es nicht lösen muss.

Der zweite Grund ist, dass ich denke, dass sie einen ziemlich schlechten Stil haben (ich weiß, dass andere Leute anderer Meinung sind). Beispielsweise:

if let 1..10 = x { .. }

Ich denke, das ist verwirrend, weil 10 nicht mit dem Muster übereinstimmt, das es enthält. Niko hat erwähnt, dass sich dies nicht wirklich von exklusiven Bereichsausdrücken unterscheidet, die nicht 10 , aber ich denke, der große Unterschied besteht darin, dass wir viele historische Präzedenzfälle (und Anwendungsfälle) im Dijsktra-Stil für die Unterstützung von exklusiven . haben reicht. Als ich zu Rust kam, erwartete ich, dass iterative & Slicing-Bereiche exklusiv sind, aber ich hatte nicht diese Erwartung für Muster.

Es hat auch das "Off-by-One"-Problem, das .. / ... in Ausdrücken hat.

Ich weiß, dass Niko erwähnt hat, dass er gerne schreiben würde:

match x {
    0..10 => { ... }
    10..20 => { ... }
}

Aber ich würde es wirklich am liebsten sehen:

match x {
    0...9 => { ... }
    10...19 => { .. }
}

Jedenfalls war ich überrascht, dass Niko meinte, dass er diese manchmal "absolut notwendig" findet, daher würde ich gerne mehr Gegenargumente hören. Da sie ein constexpr sein müssen, scheint es mir eher ein "nice to have" als ein "absolut notwendiges" Ding zu sein.

Ich fühle mich definitiv leichter bei exklusiven Bereichsmustern als bei inklusiven Bereichsausdrücken.

Das Konsistenzargument

Niko hat erwähnt, dass es für ihn aus Konsistenzgründen wichtig ist, sowohl .. als auch ... in Ausdrücken und Mustern zu haben. Ich bin von dieser Argumentation im Grunde völlig unberührt. Das Durchlaufen eines Bereichs und das Abgleichen eines Bereichs sind keine wirklich analogen Operationen, und es macht Sinn, dass es Unterschiede in der Behandlung geben würde.

Tatsächlich gibt es nicht einmal eine Implementierungsverbindung: 1..10 erzeugt einen Range-Wert, während 1...10 einem Integer-Wert entspricht. Es ist nicht so, dass sie eine strukturierende/destrukturierende Verbindung haben, wie dies bei den meisten unserer symmetrischen Ausdrucks-/Mustersyntaxen der Fall ist.

Es erscheint technisch korrekter, die Muster "Domänenmuster" zu nennen als "Bereichsmuster" 🤓, was die Nicht-Analogität hervorhebt.

@ohneboote

Niko sagt zum Beispiel, dass "exklusive Bereichsmuster irrelevant erscheinen, bis Sie sie wollen", aber ich dachte, Niko und Josh sprachen zu dieser Zeit über inklusive Bereichsausdrücke.

Ich für meinen Teil habe festgestellt, dass zu verschiedenen Zeiten sowohl exklusive als auch inklusive Bereiche notwendig sind (obwohl ich für beide Fälle exklusiv verwendet habe, um an stabilem Rust zu arbeiten, und es mit einem +1 im oberen Bereich umgehen musste gebunden). Ich möchte sie sowohl für Muster als auch für Ausdrücke verfügbar haben.

Trotzdem hätte ich persönlich keine Einwände gegen die Verwendung einer Funktion für inklusive Bereiche, außer dass ich eine Möglichkeit haben möchte, sowohl inklusive als auch exklusive Bereiche in pattern zu schreiben, und ich möchte, dass diese beiden Syntaxen nicht zum Verwechseln ähnlich aussehen wie .. und ... tun. Und angesichts einer Syntax zum Schreiben solcher Bereiche in Mustern weiß ich nicht, ob es sinnvoll ist, für solche Bereiche in Ausdrücken eine andere Syntax zu verwenden.

Ein Nachteil aller syntaktischen Lösungen ist insbesondere, dass keine von ihnen wirklich selbstdokumentierend ist. Es ist relativ nicht offensichtlich, dass 0...10 oder 0..=10 ein inklusiver Bereichsausdruck ist. Da sie relativ selten anzutreffen sind, wird dies ein Stolperstein für Benutzer sein, die ihnen zum ersten Mal begegnen.

Dem stimme ich zu. Dies kommt so selten vor, dass ich gegen eine weniger kompakte Syntax nichts einzuwenden hätte. Ich würde aber gerne einen Mechanismus haben , inklusive und exklusive Bereiche in beiden Ausdrücken und Mustern zu schreiben.

Es würde mir zum Beispiel nichts ausmachen, wenn das Schreiben eines inklusiven Bereichsmusters ein Makro oder ähnliches erfordert.

@joshtriplett Dies ist, wo ich wirklich klar sein möchte, wenn du das sagst:

Ich habe festgestellt, dass zu verschiedenen Zeiten sowohl exklusive als auch inklusive Bereiche erforderlich sind (obwohl ich für beide Fälle exklusiv verwendet habe, um an stabilem Rust zu arbeiten, und es mit einem +1 in der Obergrenze umgehen musste).

Es scheint klar, dass Sie über Ausdrücke sprechen, aber der von Ihnen zitierte Abschnitt handelte von Mustern (ich weiß, dass Sie in Ihrem nächsten Absatz über Muster sprechen, aber ich frage nach dem "Notwendigkeitsproblem", das dieser Absatz nicht anspricht 😃) .

Der Status Quo für Muster ist, dass wir nur inklusive Bereichsmuster der Form x...y . Können Sie mehr darüber sagen, ob/wann Sie es wirklich frustrierend fanden, exklusive Sortimentsmuster nicht zu haben?

@ohneboote

Können Sie mehr darüber sagen, ob/wann Sie es wirklich frustrierend fanden, exklusive Sortimentsmuster nicht zu haben?

Etwas wie

    match offset {
        0x0200 .. 0x0280 => { /* GICD_ISPENDR<n> */ }
        0x0280 .. 0x0300 => { /* GICD_ICPENDR<n> */ }
        0x0300 .. 0x0380 => { /* GICD_ISACTIVER<n> */ }
        0x0380 .. 0x0400 => { /* GICD_ICACTIVER<n> */ }
        0x0400 .. 0x0800 => { /* GICD_IPRIORITYR<n> */ }
    }

vs

    match offset {
        0x0200 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0x0280 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0x0300 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0x0380 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0x0400 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

Ich würde nicht sagen, dass es besonders frustrierend ist, aber das erste sieht auf jeden Fall schöner aus.

@ withoutboats Aus Gründen der Übersichtlichkeit wollte ich zu verschiedenen Zeiten exklusive Bereichsausdrücke, inklusive Bereichsausdrücke und inklusive Bereichsmuster. Ich kann mir nicht sofort vorstellen, dass mir eine Zeit sehr wichtig war, exklusive Sortimentsmuster zu haben, obwohl ich auch nichts dagegen hätte. Aber selbst wenn wir keine exklusiven Bereichsmuster haben, wäre es immer noch sehr verwirrend, wenn inklusive Bereichsmuster ... und exklusive Bereichsausdrücke .. .

@petrochenkov Ich nehme an, diese sollten auf F enden, nicht auf C ?

Ich bin auf den gleichen Fall mit Hex-Bereichsmustern gestoßen, zB 0x8000...0x9FFF => /* body */ . Ich finde, dass 0x8000..0xA000 etwas intuitivere Eigenschaften hat. Ohne darüber nachzudenken sehe ich sofort, dass die Größe des Bereichs 0xA000 - 0x8000 = 0x2000 beträgt und der nächste angrenzende Bereich bei 0xA000 beginnt

Der Umgang mit den +1 erforderlich sind, um diese Fakten in einem inklusiven Bereich zu sehen, ist ein kleiner Unterschied, mit dem ich leben kann, aber exklusive Bereiche (sowohl Muster als auch Ausdrücke) passen normalerweise besser zu meiner Arbeit.

@petrochenkov Ich kann verstehen, warum Sie exklusive Bereiche für Hexziffern bevorzugen (möglicherweise immer noch nicht, aber das fühlt sich wie ein sehr YMMV-Deal an).

Wie würden wir jedoch mit den Mehrdeutigkeiten der Slice-Syntax umgehen?

@joshtriplett

Ich würde es immer noch sehr verwirren, wenn inklusive Bereichsmuster ... und exklusive Bereichsausdrücke .. .

So funktioniert Rust heute und es scheint keine große Verwirrung zu geben?

@solson

Ich nehme an, diese sollten auf F enden, nicht auf C?

Nein :)
(Diese Dinge sind 32-Bit und offset ist ein Vielfaches von vier.)

@ohneboote

Ich kann verstehen, warum Sie exklusive Bereiche für Hexziffern bevorzugen (ich mag es immer noch nicht, aber das fühlt sich wie ein sehr YMMV-Deal an).

Ich sollte anmerken, dass dies keine starke Präferenz ist, ich wäre immer noch damit einverstanden, sowohl exklusive Muster als auch inklusive Bereiche fallen zu lassen (aber nicht eines davon, das wäre zu lächerlich).

Wie würden wir jedoch mit den Mehrdeutigkeiten der Slice-Syntax umgehen?

Leicht! PATTERN.. => .. @ PATTERN

Mein Hauptgrund dafür, dass inklusive Bereiche einfach sein sollen, ist, dass ich mehr als einmal auf Situationen gestoßen bin, in denen ich einen Stoppwert in einer Variablen übergebe und es genau der maximale Wert ist, den ein Variablentyp aufnehmen kann, also die einzigen Lösungen Um einen Überlauf zur Kompilierzeit auszuschließen, sind:

1. Verwendung eines Inklusivbereichs (am saubersten, aber nicht stabil)
2. Upcasting vor dem + 1 (vorausgesetzt, ich bin noch nicht auf u64 und unelegant)
3. Nehmen Sie den kleineren Wert und das Maximum minus eins für den Bereich und führen Sie die Aufgabe gegebenenfalls noch einmal aus.

Der Aufbau eine Gewohnheit, mit inklusive Bereichen anstatt das Hinzufügen + 1 zu einem Algorithmus , wo es keinen inhärenten Zweck hat , ist eine nicht-triviale Weise , um gegen sie später wieder in der Begegnung cargo fuzz ... und mit Eine Funktion "Make Inclusive from Exclusive" mit mehr Zeichen in ihrem Namen als + 1 erweckt den Eindruck, dass inklusive Bereiche eine außergewöhnliche Sache sind und nicht etwas, das Sie gewöhnlich verwenden sollten.

Das ist einer der Hauptgründe, warum ich dagegen bin. Es vermittelt den Eindruck, dass inklusive Bereiche ein Hack sind, der verwendet werden sollte, wenn sich herausstellt, dass exklusive Bereiche fehlgeschlagen sind.

@ssokolow, aber dieser Anwendungsfall wird bequem durch eine Vorspielfunktion abgedeckt. Niemand vertritt die Position, dass es nicht möglich sein sollte, inklusive Bereiche zu erstellen, nur ob sie syntaktischen Zucker haben sollten, um sie zu erstellen.

Ich mag @ Withoutboats Idee einer Vorspielfunktion. Ich denke, der andere Ort, an dem inklusive Bereiche häufiger vorkommen, ist, wenn Sie keine Ganzzahlen verwenden, z. B. durch Angabe der Grenzen einer Suche in einem btree (oder einer ähnlichen Datenstruktur).

@Withoutboats Ich habe meinen Beitrag ein wenig bearbeitet, während Sie geantwortet haben, aber das Wesentliche von dem, was ich hinzugefügt habe, ist, dass inklusive Bereiche syntaktisch Bürger zweiter Klasse sind (mit einer Syntax, die länger ist als das Hinzufügen von + 1 zu einem exklusiven Bereich ), fühlt sich wie eine subtile Entmutigung an, sie zu verwenden, und eine mögliche "Wir sehen uns in cargo fuzz später"-Fußwaffe.

Wenn nichts anderes, ist es eine Belehrbarkeitswarze.

Rust ist nicht Python 3.x mit seiner unbegrenzten Integer-Unterstützung. Rust verbirgt die Hardware-Kompromisse nicht vor Benutzern, und ich sehe das ..= ich bevorzuge, nur als Teil der Verwendung von u32 und Freunden anstelle von int . (Vor allem, da Überlauf-/Unterlauffehler bisher am häufigsten im "Trophäenfall" von cargo fuzz aufgetreten sind.)

EDIT: Bitte ignorieren Sie dafür alle Bits, die Sie nur in den E-Mail-Benachrichtigungen sehen. Ich bin gerade aufgewacht und feuere noch nicht aus allen Zylindern.

Ich sehe inclusive(n..m) als Entmutigung... Ich würde es vorziehen, es zu schreiben, weil es eine sehr klare Konstruktion ist, die meinen Code leichter zu lesen macht als sowohl n..(m + 1) als auch n..=m (was ich für unnötig seltsam halte, wenn wir nur das Wort "inklusive" sagen könnten).

n..=m ist eher eine Lernschwäche als inclusive(n..m) IMO.

Ich denke, dass für Match der Wunsch besteht, eine vollständige Abdeckung des numerischen Bereichs zu haben, anstatt eine bestimmte Art von Muster.

Vermutlich würde es das Problem auch lösen, wenn es eine Syntax "von vorheriger fortsetzen" gäbe.

Übrigens, da nur das erste Muster übereinstimmt, kann die Startnummer oft weggelassen werden:

    match offset {
        0 ... 0x01FF => {}
        0 ... 0x027C => { /* GICD_ISPENDR<n> */ }
        0 ... 0x02FC => { /* GICD_ICPENDR<n> */ }
        0 ... 0x037C => { /* GICD_ISACTIVER<n> */ }
        0 ... 0x03FC => { /* GICD_ICACTIVER<n> */ }
        0 ... 0x07FC => { /* GICD_IPRIORITYR<n> */ }
    }

Ich gebe zu, dass dies eine Frage der Perspektive sein kann, aber:

1. Wenn ich .. und ..= sehe, denke ich "Huh. Ich frage mich, warum sie zwei Syntaxen für einen so kleinen Unterschied haben", was mich dann dazu bringen würde, nach Dokumenten zu suchen, auf die ich mich konzentrieren könnte " 1..pivot und pivot..end " vs. " x..=y wobei y der maximal mögliche Wert sein kann".

2. Bevor ich erfahren genug war, um gewohnheitsmäßig in Bezug auf variable Größen zu denken, hätte ich einfach + 1 über inclusive() (wenn ich überhaupt danach gesucht hätte), weil ich es benutzt habe + 1 seit der Grundschule ist es kurz und einfach zu tippen, und mein unerfahrener Mensch ist es gewohnt, in Sprachen wie Python und JavaScript zu arbeiten, wo Additionen, die einen Überlauf verursachen, nichts sind, worüber sich die Leute Sorgen machen.

EDIT: ...und es ist diese konzeptionelle Unterscheidung in Punkt 1, auf die wir uns meiner Meinung nach konzentrieren sollten. (dh, dass "von X zum Pivot" und "von X zum Ende" im Kopf des Programmierers unterschiedlich sein sollten.)

@pornel
Das ist schrecklich
In diesem speziellen Fall ist der Bereichsstart wirklich sehr wichtig für eine Person, die den Code liest, viel wichtiger als alle inklusiven/exklusiven Bereichsprobleme.

@ssokolow es scheint mir, dass +1 nicht die Anzahl der Zeichen zu einem Problem macht, sondern dass Sie mit dem Überlaufpotenzial umgehen müssen. Es kommuniziert auch nicht so gut die Absicht und erfordert streitende Vorrang-Eltern. Diese scheinen alle viel wichtiger zu sein als die Anzahl der Zeichen.

Es stimmt, dass jemand, der sich nicht mit Überlauf auskennt, möglicherweise nach +1 greift, bevor er einen einschließenden Bereich erstellt, aber dies scheint nicht von der Syntax abhängig zu sein. Sowohl die Entdeckung, dass ..= eine Sache ist, als auch inclusive() eine Sache ist, bietet den lehrreichen Moment, um zu erfahren, warum Sie speziell inklusive Bereiche möchten.

@petrochenkov

Ich wäre immer noch damit einverstanden, sowohl exklusive Muster als auch inklusive Bereiche fallen zu lassen (aber nicht eines davon, das wäre zu lächerlich) .

Könnten Sie erläutern, warum Ihnen das so wichtig ist? Ich sehe das Akzeptieren exklusiver Muster definitiv nur als Nachteil an, da es dazu führen könnte, dass Benutzer 0...10 als Ausdruck erwarten, aber das scheint mir nicht so schlimm zu sein.

Ein Teil meines Problems mit inclusive() ist, dass es "nur" eine Funktion ist und ich befürchte, dass die Leute Dinge wie den Rust-Syntaxindex aufrufen, nach "range" oder "iterator" suchen und dann einen unzureichenden ROI annehmen für "Sehen[ing] Iteratoren".

("Ich möchte kein Lehrbuch lesen, wenn ich zufällig etwas Nützliches finde ... Ich möchte nur über einen Bereich iterieren und wieder Fortschritte machen.")

@ withoutboats Wenn wir inclusive (a..b) haben, es aber nicht im Spiel verwenden können, lohnt es sich IMO nicht.
Die meiste Zeit, wenn ich Inklusivbereiche verwende, ist es in Übereinstimmungsmustern!
Warum können wir also nicht ... entfernen und einfach ..= innerhalb und außerhalb des Spiels verwenden?

@Boscop der Vorschlag ist nicht, ... im Spiel zu entfernen, sondern Muster genau so zu belassen , wie sie in Stable sind.

@ssokolow scheint das ziemlich einfach mit einer Notiz im Abschnitt .. zu lösen

@Withoutboats Aber warum nicht ... im Spiel entfernen und stattdessen ..= verwenden, damit es konsistent ist?
(sodass es ..= innerhalb und außerhalb des Spiels wäre)

Für die numerische Bereichsabdeckung in Gleitkommazahlen hilft Exklusiv. Beispielsweise ist eine dieser Grenzen vollständig abgedeckt, die andere jedoch nicht:

match x {
    0.0...3.141592653589792 => 1,
    3.141592653589793...6.283185307179585 => 2,
    6.283185307179586...10.0 => 3,
    _ => 4,
}

Und es stattdessen mit Überlappungen zu schreiben, fühlt sich eklig an (und moralisch ähnlich wie oben "einfach alles von -∞ da die Arme geordnet sind"). Siehe auch datetimes, wie ISO8601 T24:00 zulässt, da ein Tag [00:00, 24:00] ist, nicht [00:00, 23:59:59]. Oder Strings, oder rationals, oder ...

Bei der Wahl zwischen nur exklusiv oder nur inklusive, nehme ich jedes Mal exklusiv.

(Außerdem: Das 1 <= x <= N Muster für die Indizierung ist eigentlich besser als 0 < x <= N , das auch exklusiv ist - obwohl halb geschlossen statt halb offen - aus den gleichen Gründen, sagte Dijkstra, nur für 1-basierte Indizierung anstelle von 0-basiert umgeschaltet.)

Dieser Operator wäre für die Klemmfunktion, die ich hier vorgeschlagen habe, sehr hilfreich gewesen: https://github.com/rust-lang/rfcs/pull/1961 Da dies jedoch nicht stabilisiert wurde, muss ich diesen Vorschlag wahrscheinlich ändern verwenden Sie stattdessen zwei min- und max-Argumente. InclusiveRange ist auch beim Arbeiten mit Gleitkommawerten sehr hilfreich, sodass wir Folgendes nicht tun müssen:

0.0..1.0+EPSILON

Ich bin mir nicht einmal sicher, ob das richtig ist, aber im Moment ist es sehr schwierig, einen inklusiven Bereich von Gleitkommazahlen zu deklarieren.

Der richtige Weg, dies zu tun, wäre nextafter , nicht Epsilon. dh x...y == x..nextafter(y) . ieee754 Crate bietet solche Funktionen

Hoppla, ich habe einen Kommentar zur inclusive(a..b) Syntax abgegeben, aber mir wurde klar, dass das nicht stimmt. Wie auch immer, ich mag es, aber ich hoffe, wir können einen besseren Namen für Bikeshed.

@durka Der Name scheint mir klar. Können Sie Ihre Bedenken damit präzisieren?

Für inklusive Bereiche haben wir also a ... b in match und inclusive(a..b) außerhalb des Spiels?
Warum können wir nicht konsequent sein und a ..= b überall haben?

Gibt es etwas, das ops::{RangeInclusive, RangeToInclusive} davon abhält, formell stabilisiert zu werden?

Im Moment scheint es, als ob die Debatte über die Syntax der Hauptblocker ist, obwohl ich unabhängig von dieser Debatte ziemlich sicher bin, dass inklusive Bereiche unabhängig von der Endsyntax existieren werden.

Es wäre schön, diese Typen für stabile Bibliotheken zu implementieren, und dann können die Verbraucher dieser Bibliotheken entscheiden, das Feature-Flag zu aktivieren, wenn sie die spezielle Syntax verwenden möchten.

Eine Sache, die mir neulich bei RangeInclusive aufgefallen ist: Es ist mühsam, dagegen zu programmieren, wenn Sie versuchen, einen Bereich zu akzeptieren. Der Klemmen-Thread sprach davon, .clamp(1...9) zuzulassen, aber der Code sieht am Ende ungefähr so ​​​​aus:

    fn clamp(self, r: RangeInclusive<Self>) -> Self where Self : Sized {
        match r {
            RangeInclusive::Empty { .. } =>
                panic!("Cannot clamp to an empty range"),
            RangeInclusive::NonEmpty { start, end } => {
                assert!(start <= end, "Cannot clamp to a degenerate range");
                if self < start { start }
                else if self > end { end }
                else { self }
            }
        }
    }

Es fühlt sich unnötig an, mit RangeInclusive::Empty umgehen zu müssen, da das Ziel nur darin besteht, das Paar mit einer schönen Syntax zu akzeptieren. Wenn es keine Aufzählung wäre, könnte es nur fn clamp(self, RangeInclusive { start, end }: RangeInclusive<Self>) und viel sauberer sein.

Leider habe ich jedoch keine gute Antwort darauf, was ich dagegen tun soll, da es auch bedauerlich wäre, .into_iter() auf inklusive, aber nicht exklusiv zu fordern ...

Zufällige Idee: Da die Syntax des ... Musters nicht wirklich mit den inklusiven Bereichstypen zusammenhängt, könnten wir erwägen, ihre Syntax zugunsten einer Syntax abzulehnen, die nichts mit den hier vorgeschlagenen ... tun hat.

Da ein inklusives Bereichsmuster enger mit dem | Muster verwandt ist, könnte |... ein guter Kandidat sein:

match {
    1 | 2 | 3 => ...
    1 |... 3  => ...
}

Das Endergebnis wäre, dass die Syntax von inklusiven und exklusiven Bereichen keine 1:1-Beziehung mehr zum Mustervergleich hat und daher nicht damit konsistent sein muss.

@scottmcm

Leider habe ich jedoch keine gute Antwort darauf, was ich dagegen tun soll, da es auch bedauerlich wäre, .into_iter() auf inklusive, aber nicht exklusiv zu fordern ...

Vielleicht könnten wir einen Helfer wie range.nonempty() hinzufügen, der bei einem leeren Bereich in Panik gerät und ein Paar zurückgibt?

Alternativ könnten wir IntoIterator für RangeInclusive implementieren und es wäre IMHO nicht allzu weit weg.

Welchen Anwendungsfall bietet RangeInclusive::Empty? Warum muss ein inklusiver Bereich einen leeren Bereich darstellen können? Wie würdest du einen schreiben? (Beachten Sie, dass Sie bereits Dinge wie "der Bereich von 5 bis einschließlich 4" schreiben können, die die Iteration vermutlich als leer behandeln würde.)

@joshtriplett Der Hauptfall ist Überlauf, obwohl es Möglichkeiten gibt, dieses Problem zu lösen.

@joshtriplett start > end funktioniert in einem wichtigen Fall tatsächlich nicht, um den leeren Inklusivbereich darzustellen: 0u8...255u8 . Wenn Sie bei 255u8...255u8 ankommen und versuchen, es zu .next() machen, bekommen Sie entweder eine Panik oder brechen auf 0u8...255u8 , was nicht leer ist. Stattdessen wechseln wir an dieser Stelle zur Variante Empty .

@solson Ah, ich ist einer der größten Anwendungsfälle für inklusive Bereiche.

(Ich gehe davon aus, dass Sie in all diesen Fällen 255u8 meinen.)

(Ich gehe davon aus, dass Sie in all diesen Fällen 255u8 meinen.)

Ja Danke. Bearbeitet.

@solson , dieser Fall kann jedoch behoben werden, indem man in diesem Fall 0 und 255 vertauscht

@clarcharr Das stimmt. Da .next() die Generierung eines Empty Bereichs immer mit Sonderfällen versehen muss, könnte es immer einen Bereich generieren, der als leer behandelt wird.

Mir persönlich gefällt das besser, weil es nicht um den leeren Bereich geht.

Der Thread läuft also schon seit anderthalb Jahren. Ich habe mir gerade alles durchgelesen und möchte für Neulinge eine kurze Zusammenfassung posten und uns hoffentlich bei der Entscheidungsfindung helfen:

Was Rust Stable heute macht:

0..5 stellt einen halboffenen Bereich dar, [0, 1, 2, 3, 4], der nicht beim Mustervergleich verwendet werden kann
0...5 repräsentiert einen geschlossenen Bereich [0, 1, 2, 3, 4, 5], der nur beim Mustervergleich verwendet werden kann.

Mehrere Formen wurden für eine zusätzliche Syntax mit geschlossenem Bereich vorgeschlagen, die außerhalb des Mustervergleichs verwendet werden kann. Ich werde jeden einzelnen und die Vor- und Nachteile von ihnen behandeln.

0...5

Vorteile: In Übereinstimmung mit der bestehenden Mustervergleichssyntax fühlt sich die Sprache zusammenhängender an, vorausgesetzt, es werden keine Änderungen an der Mustervergleichssyntax vorgenommen.

Nachteile: Leicht zu vertippen und durch einen Fehler zu verursachen, auch leicht die Absicht zu missverstehen, da andere Sprachen diesen Operator verwenden, um unterschiedliche Konzepte zu kommunizieren.

0..=5

Vorteile: Schwerer zu vertippen, semantisch klarer

Nachteile: Inkonsistent mit der bestehenden Mustervergleichssyntax. Kann dazu führen, dass Benutzer fragen: Warum ist es ... hier, aber ..= hier?

0..^5

Sehr ähnlich zu ..= , hat aber den zusätzlichen Nachteil, dass es wie ein Potenzierungsoperator aussieht.

inclusive(0..5)

Positiv: Sehr semantisch klar. Wird sich nicht vertippen.

Nachteile: Etwas lang. Auch inkonsistent mit der Syntax für den Mustervergleich.

0....5

Vorteile: Verhindert auch das Tippfehler von ...

Nachteile: Schlechte Semantik, inkonsistent mit der Syntax für den Mustervergleich und ähnlich der Syntax für den Mustervergleich.

[0..5] Unbrauchbar. Klammern haben in der Sprache bereits syntaktische Bedeutung.

0..<=5 Nicht verwendbar. Steht in Konflikt mit der vorhandenen Syntax, um einen Wert mit einem Bereich zu vergleichen.

Jede aufgelistete Option, die den Nachteil "inkonsistent mit der Syntax für den Mustervergleich" hat, könnte verbessert werden, wenn wir die Syntax für den Mustervergleich ändern würden, aber dieser Weg hat Abwärtskompatibilitätsprobleme. Alternativ könnten wir auch ... und (wählen Sie hier Ihre Syntax) innerhalb des Mustervergleichs äquivalent machen, um die Abwärtskompatibilität zu vermeiden, aber die Verwendung von ... außerhalb des Mustervergleichs zu verhindern. Vielleicht könnten wir auch den Styleguide aktualisieren, um die Verwendung von ... beim Mustervergleich zu verhindern, wenn wir diesen Weg einschlagen würden.

Es gab auch einige Diskussionen über die Erstellung einer allgemeineren Bereichssyntax, mit der Sie sowohl die obere als auch die untere Grenze einschließen oder ausschließen können, aber wir brauchen diese Syntax wahrscheinlich nicht einmal, da halboffene und geschlossene Bereiche wahrscheinlich überdecken 99,9999% der Anwendungsfälle.

Ich habe versucht, diese Diskussion so gut wie möglich darzustellen. Wenn Sie der Meinung sind, dass ich Ihren Standpunkt nicht angemessen ausgedrückt habe, lassen Sie es mich bitte wissen, damit ich dies aktualisieren kann.

@Xaeroxe Danke für die hervorragende Zusammenfassung.

Vielleicht ist es möglich, ein Tool (vielleicht ein Plugin von rustfmt) zu haben, das Quellen automatisch von der Verwendung von ... beim Mustervergleich in die neue Syntax (zB ..= ) umwandelt, wenn dies entschieden ist.
Auf diese Weise werden wir nicht von "allem Code, der auf die alte Weise geschrieben wurde" zurückgehalten.
Aber es muss mit Absicht von den Projektautoren aufgerufen werden und es sollte eine Benachrichtigung / Überschrift auf allen Rostmedien geben, damit jeder über die Änderung informiert ist.
Mit diesen Dingen denke ich, ist es kein Problem, die ... Syntax im Mustervergleich auf die neue Syntax zu ändern.

Ich denke, eine Sache, die wir tun könnten, um das Syntaxproblem zu lösen, besteht darin, RangeInclusive zu stabilisieren, wie

Wir könnten auch die Funktion inclusive hinzufügen (entweder nur zu std::range oder möglicherweise auch zum Präludium); Dies schließt nicht aus, eines Tages eine erstklassige Syntax zu haben, aber es macht es viel bequemer, jetzt ein RangeInclusive zu konstruieren.

All dies scheint jedoch wie libs-Entscheidungen zu sein, daher weiß ich nicht, ob das Lang-Team zuständig ist, um zu entscheiden, diese Elemente zu stabilisieren / hinzuzufügen 😅.

Ich persönlich würde es vorziehen, RangeInclusive selbst in etwas umzuwandeln, das keine Empty Variante hat, und dann ein IntoIter mit der Variante zu machen. Es macht für mich mehr Sinn, wenn man bedenkt, dass es im Wesentlichen unmöglich ist, einen leeren Bereich ohne manuell Empty { at } zu konstruieren.

Alternativ können Sie MAX und MIN für den von mir erwähnten Randfall tauschen. Das macht es schwieriger, allgemeineren Code mit RangeInclusive zu schreiben, aber es scheint eine vernünftige Lösung für das Problem zu sein.

Unabhängig davon, was passiert, unterstütze ich nachdrücklich die Stabilisierung des Typs in der Standardbibliothek, die unabhängig von Syntaxproblemen vorhanden sein wird. Es ermöglicht Bibliotheken, stabilen Code zu schreiben, der das Slicing mit einschließenden Bereichen ermöglicht, sodass die Leute zum Zeitpunkt der Stabilisierung der Syntax bereits den Code implementiert haben, der die Typen verwendet. Syntax und Typen stehen aus einem bestimmten Grund unter verschiedenen Feature-Flags.

@scottmcm Ich stimme zu, dass dies an dieser Stelle wahrscheinlich ein separater Thread sein sollte.

In einem Versuch, die Syntaxdiskussion voranzutreiben, werde ich den Weg anbieten, den ich am liebsten einschlagen würde.

Ich mag die Syntax ..= am liebsten, daher denke ich, dass wir diesen syntaktischen Zucker als gleich ... im Mustervergleich und als InclusiveRange außerhalb des Mustervergleichs hinzufügen sollten. Um die Sprache konsistent zu halten, sollten wir dann versuchen, Benutzer und ihren Code mithilfe von Ankündigungen und automatisierten Tools in Mustern auf die ..= Syntax zu migrieren. Sobald wir der Meinung sind, dass wir genug Benutzer von ... haben, können wir eine Compiler-Warnung und dann (möglicherweise sogar in Jahren) einen Compiler-Fehler verwenden.

Es ist 24 Tage her, dass mein Vorschlag vorgelegt wurde, und es wurden keine Kommentare abgegeben. Sollen wir mit diesem Plan vorankommen?

EDIT: Auf dem Handy habe ich die Daumen nach unten nicht gesehen, also wusste ich nicht, dass es abweichende Meinungen gibt.

@Xaeroxe Ich glaube nicht. Ich stimme nicht zu, dass es eine gute Wahl ist, ... zugunsten von ..= abzulehnen, aus Gründen, die ich bereits in diesem Thread gepostet habe. Auf Ihren konkreten Vorschlag habe ich nicht geantwortet, da dieselbe Idee bereits vorgebracht und diskutiert wurde. Klar ist hier nur, dass wir keinen Konsens haben. Ich denke, viele von uns fühlen sich durch die Diskussion müde.

BEARBEITEN: Um genauer zu sein, möchte ich ... zugunsten von ..= weil:

• Das Verwerfen der Syntax ist ein enormer Kostenfaktor bei der Abwanderung; selbst wenn mir ..= eindeutig gefallen würde, glaube ich nicht, dass es den veralteten Zyklus wert wäre, nur um inklusive Bereichsausdrücke auf stable zu bekommen.
• Ich weiß nicht wie ..= , ich denke , es ist nicht offensichtlich und unklar; Es hat den Vorteil, dass es weniger wahrscheinlich zu Fehlern führt, aber das bedeutet nicht, dass ein Benutzer, der es zum ersten Mal sieht, weiß, was er sieht.
• Ich bin nicht mit der Prämisse einverstanden, dass hier eine Symmetrie zwischen Mustern und Ausdrücken bestehen muss, da sie keine analogen Strukturierungs-/Destrukturierungsoperationen durchführen.

(Ich verändere die Ansichten während dieses Kommentars ein wenig, ich beschloss, alles zu belassen, damit andere meinen Denkprozess sehen und warum ich zu den Schlussfolgerungen gekommen bin, die ich gemacht habe)

Zu den Kosten der Abschreibung kann ich aufgrund meiner mangelnden Erfahrung mit solchen Dingen nichts sagen. Ich unterstütze jedoch immer noch ..= .

Ich denke, an einem bestimmten Punkt müssen wir bereit sein, die Benutzer zu bitten, etwas zu lernen. Programmieren als Ganzes muss man lernen, spezialisierte Syntax im Allgemeinen geht immer auf Kosten der Semantik. Ich erwarte nicht, dass die Leute die Syntax auf den ersten Blick erkennen, .. ist in dieser Hinsicht genauso schlecht.

Allerdings kann ein Überfluss an spezialisierter Syntax dazu führen, dass eine Sprache eher dem Brainfuck ähnelt, als wir Rust haben wollen. Wir müssen also aufpassen, dass die Fälle, die wir in eine spezielle Syntax umwandeln, tatsächlich häufig genug sind, um sich zu lohnen. Um ehrlich zu sein, jetzt, wo ich das geschrieben habe, bin ich mir nicht ganz sicher, ob dieser Fall das wert ist. Der Bedarf an inklusiven Bereichen ist nicht hoch genug, um eine Syntax zu rechtfertigen.

Trotzdem stört mich die Ungereimtheit. Eine einschließende Funktion und ... im Mustervergleich zu haben, fühlt sich an, als hätte man in der englischen Sprache sowohl Grau als auch Grau. Wenn wir die Möglichkeit haben, dies zu standardisieren, fühlt sich ein Teil von mir so an, wie wir es sollten. Es gibt jedoch auch tatsächliche logistische Probleme bei dieser Änderung. Wenn wir jemals einen Rust 2.0 entwerfen sollten (das könnte verrückt sein, ich habe keine Ahnung), sollten wir das vielleicht noch einmal überdenken, aber ich denke, für den Moment ist es gut genug, sowohl Grau als auch Grau zu haben.

Ich unterstütze derzeit die Verwendung einer inclusive Funktion für Instanzen außerhalb des Musterabgleichs und ... beim Musterabgleich.

@ohneboote

1. Wenn Sie nie etwas missbilligen, landen Sie bei der Vereinigung aller (mehr oder weniger) schlechten Entscheidungen wie C++. Dies zwingt Neulinge dazu, noch mehr zu lernen, da die Dinge nicht so konsistent sind, wie sie sein könnten.
   Daher ist es manchmal sinnvoll, Dinge abzulehnen, um Platz für die bessere Lösung zu schaffen.

2. Das bedeutet nicht, dass ein Benutzer, der es zum ersten Mal sieht, weiß, was er sieht.

Dies ist bei jeder Syntax der Fall. Wir (die Rust kennen) haben diese Voreingenommenheit, weil für uns Rust-Code offensichtlich aussieht, aber jeder, der aus einer anderen Sprache zu Rust kommt, muss oft die Syntax nachschlagen. Es ändert sich nicht, wenn wir ..= oder ... oder eine andere Syntax für inklusive Bereiche verwenden, weil andere Sprachen zB ... für exklusive Bereiche verwenden, also müssen sie es trotzdem nachschlagen .
Es sollte nicht unser Ziel sein, nur offensichtlich aussehende Funktionen einzuführen:
Wenn wir nur Funktionen haben wollten, die offensichtlich aussehen, könnten wir die meisten der vorhandenen Funktionen in Rust nicht haben. Neulinge MÜSSEN sowieso in den Doc schauen, was ist daran so falsch? Der Doc ist gut!

1. 
   Wenn es Ihnen wichtig ist, die Zeiten, in denen Neulinge in die Dokumentation einsehen müssen, zu minimieren, sollten wir eine Symmetrie zwischen Konstruktion und Abstimmung von Inklusivbereichen anstreben! (und andere Konstrukte)

Wie @Withoutboats sagte, ich denke, viele von uns sind dieser Diskussion überdrüssig; Ich für meinen Teil habe es eine Weile ausgesessen. Trotzdem habe ich mir etwas Zeit genommen, um es noch einmal zu lesen (danke für die Zusammenfassung @Xaeroxe!)

IMO, das wichtigste Problem im Moment ist die unvollständige Kombination von Syntaxen, die wir anbieten : ... in Mustern, .. für Ausdrücke. Dieses Syntaxpaar lässt Sie stark erwarten, dass .. in Mustern und ... in Ausdrücken funktionieren würde – und das tun sie nicht. Ich glaube, dass dies auf lange Sicht kein haltbares Design ist, und möchte es wirklich reparieren.

Ich denke auch, dass es wahrscheinlich am besten ist, dies fortzusetzen, da wir die Syntax für beide Arten von Bereichen bereitgestellt haben. Das lässt uns ein paar Möglichkeiten:

• Stabilisieren Sie ... in Ausdrücken und fügen Sie .. zu Mustern hinzu. Dies ist die am wenigsten schmerzhafte Änderung, hat aber gut diskutierte Nachteile bei Einzelfehlern. Dennoch haben andere Sprachen diese Kombination und haben meines Wissens nicht so sehr unter solchen Fehlern gelitten.

• Veralten Sie ... in Mustern und Ausdrücken, fügen Sie ..= zu beiden hinzu und fügen Sie .. zu Mustern hinzu. Behebt die oben genannten Nachteile, ist schmerzhafter (wegen der Einstellung) und öffnet die Tür zu anderen Arten von Bereichen (wie links-exklusiv) in der Zukunft.

An dieser Stelle beginne ich die Diskussion weitgehend neu, und ehrlich gesagt, ich glaube nicht, dass es an dieser Stelle viel mehr zu sagen gibt; Ich denke, wir haben die Kompromisse aufgedeckt und brauchen nur das lang-Team, um eine Bewertung vorzunehmen und eine Entscheidung zu treffen. Aber der Hauptgrund meines Kommentars ist der Ausgangspunkt, warum ich denke, dass sich hier etwas ändern muss (und warum es nicht ausreicht, nur inclusive hinzuzufügen, IMO).

Dennoch haben andere Sprachen diese Kombination und haben meines Wissens nicht so sehr unter solchen Fehlern gelitten.

Ich mache mir hier Sorgen über die Auswahlverzerrung. Ob die Probleme geringfügig sind oder uns nur selten auffallen, können wir nicht zuverlässig beurteilen.

Außerdem fühlt sich die Verwendung von ... so an, als würde dies dem Aspekt "Fußwaffen vermeiden, es sei denn, die Kompromisse sind zu streng" von Rusts Designphilosophie und neuen Best Practices zuwiderlaufen. (zB der Rat, neue enum Typen zu erstellen, anstatt bool damit es schwieriger ist, Ihre Funktionsparameter zu verwechseln.)

C hat beispielsweise bewiesen, dass Zuweisungen in if Anweisungen nützlich sind, wenn eine Sprache nicht while let , aber es wurde erkannt, dass = wenn Sie == meinten

Umgekehrt hatte ich Clippy tatsächlich einen Fall wie diesen erwischt, als ich vor ungefähr einer Woche müde kodierte ...

foo == bar;  // This should be `foo = bar;`

...was wie ein perfektes Beispiel für die Art von "Taste zu oft gedrückt"-Fehler erscheint, über die wir uns hier Sorgen machen... und im Gegensatz zu " == hat keine Auswirkung" gibt es keine gute Möglichkeit, für .. Vergleich zu ... .

@ssokolow Um es klar zu ..= einverstanden ; Ich glaube nicht, dass die Einstellung so schmerzhaft sein wird, und es ist eine sehr einfache automatische Lösung. Hauptsächlich möchte ich nur dieses Problem gelöst bekommen.

Ich kann wahrscheinlich damit leben, .. / ... zu stabilisieren (was bereits auf nightly implementiert ist). Ich stimme @aturon zu, dass die vorhandene Sprache darauf hindeutet, dass dies funktioniert.

Wie ich bereits sagte, würde ich den libstd-Typ gerne stabilisieren, wenn rust-lang/rfcs#1980 erfolgreich ist, ohne dass eine Syntaxdiskussion erforderlich ist.

Neben dem, was @aturon darauf hingewiesen hat, wäre es vielleicht nützlich, die Tracking-Probleme sowohl für diese als auch für die exklusive Bereichssyntax zusammenzuführen? Machen Sie vielleicht ein separates Nachverfolgungsproblem für den Typ und verwenden Sie es, um den Typ vor der Syntax zu stabilisieren.

Ich nominiere erneut für die Diskussion im Lang-Team. Ich halte es für sehr unwahrscheinlich, dass sich zu diesem Zeitpunkt signifikant neue Ideen oder Kompromisse ergeben werden. Wir müssen eine Entscheidung über die vereinbarten Kompromisse treffen.

Am 18. Mai 2017 9:55:30 PDT schrieb Aaron Turon [email protected] :

Ich nominiere erneut für die Diskussion im Lang-Team. Ich halte es für sehr unwahrscheinlich
dass sich dabei wesentlich neue Ideen oder Kompromisse ergeben werden
Punkt. Wir müssen eine Entscheidung über die Kompromisse treffen, die getroffen wurden
ausgelegt.

Ich werde wegen einer Konferenz zum Meeting nächste Woche abwesend sein. Falls dies in der Sitzung nächste Woche diskutiert wird, werde ich meine Unterstützung für jede andere Lösung als ... , egal ob ..= , inclusive oder andere.

Es würde sich lohnen, die Rest/Spread-Syntax zu diskutieren, wenn wir schon dabei sind.
Ich stimme .. für exklusiven Bereich, ... für inklusive, .... für Rest/Spread.

take_range(..max); // exclusive range
take_range(...max); // inclusive range
take_multiple_args(....tuple); // spread
if let 0..10 = get_num() {} // exclusive range pattern
if let 0...9 = get_num() {} // inclusive range pattern
if let [first, ....rest] = get_slice() {} // rest pattern

Ich würde aus zwei Gründen für ... für eine Restscheibe stimmen:

1. Die Leute sind wahrscheinlich bereits mit ... vertraut, was "Rest" bedeutet, aus Sprachen wie CoffeeScript (CoffeeScript verwendet rest... in Funktionssignaturen für Varargs und nennt sie "splats") und Englisch (mit dem richtigen Unicode Codepunkt oder nicht, es sind drei Punkte, die wie Auslassungspunkte aussehen, nicht vier, und die Leute verstehen die Auslassungspunkte anständig, um ungefähr "und es gibt noch mehr, aber wir sagen es nicht laut" auf Englisch zu bedeuten, nur weil sie darauf stoßen in Benutzung.)

2. Sofern ich nicht etwas über Rusts Syntax vermisse, würde die Verwendung von .. und ..= für Bereiche, aber ... für Rest-Slices bedeuten, dass in jeder Situation die Eingabe von ... wenn Sie .. oder umgekehrt meinten, wäre immer noch ein Fehler bei der Kompilierung.

   Dabei gehe ich von zwei Annahmen aus:

   1. Dass die alleinige Verwendung der Rest-Syntax (außerhalb eines Sequenz-Entpack-Kontexts) als tippfehleranfälliger No-Op nicht zulässig ist. (dh for _ in ...rest wäre dasselbe wie for _ in rest falls erlaubt, aber mit ziemlicher Sicherheit ein Tippfehler.

   2. Die Verwendung eines offenen Bereichs als Muster, dem zugewiesen werden soll, wäre ungültig. (dh let [first, ..rest] = wäre ungültig.)

@ssokolow Dreifachpunkt bedeutet bereits einen Bereich im Muster, so dass es eine bahnbrechende Änderung wäre, ihn in die

@phaux- Punkt. Das hatte ich aus irgendeinem Grund vergessen.

Etwas, um vielleicht an das Tag "Wenn wir jemals Rust 2.0 machen" zu hängen.

Dreifachpunkt bedeutet bereits einen Bereich im Muster, so dass es eine bahnbrechende Änderung wäre, ihn in die Restsyntax zu ändern.

Allerdings muss das ... in Mustern auf beiden Seiten einen Ausdruck haben, glaube ich ( a...b ), während die restliche Syntax ... als Präfix verwendet, nicht wahr?

Das lang-Team hat dieses Feature in unserem heutigen Meeting noch einmal diskutiert und ist zu ungefähr folgender Matrix gekommen:

• Die Unterstützung von ... in Mustern und .. in Ausdrücken und nichts anderes ist ein unhaltbares Design; es führt dazu, dass Benutzer erwarten, dass eine Syntax funktioniert, die nicht funktioniert.

• Es würde helfen, ... und .. an beiden Stellen zuzulassen, aber das Einzelproblem ist ein echtes Problem; Keiner von uns ist begierig darauf, Berichte von Leuten zu erhalten, die Stunden damit verbringen, eine fehlerhafte Periode aufzuspüren.

• Der Wechsel zu ..= und .. ist ästhetisch weniger ansprechend, vermeidet aber die oben genannten sehr realen praktischen Probleme. Wir können es auch auf sehr sanfte Weise einführen: Führen Sie zuerst ..= als alternative Syntax ein (die rustfmt umschreiben kann) und erst nachdem es idiomatisch geworden ist, deprecieren Sie ... .

Falls Sie es nicht sagen können, das Team ist der Meinung, dass ..= und .. unser bester Weg sind. Dieses Thema wurde auch so weit diskutiert, dass es sehr unwahrscheinlich ist, dass neue Argumente vorgebracht werden, also sind wir bereit, den Sprung zu wagen: Wir suchen jemanden, der die ..= Notation für beide implementieren möchte Muster und Ausdrücke, und anschließend gehen wir zu FCP!

Zu diesem Zweck suchen wir jemanden (oder einige Leute), der die Implementierung vorantreibt. Wahrscheinlich kann dies in einer Reihe kleinerer PRs getan werden:

• Um zu beginnen, fügen wir dem Parser ..= als Alias ​​für ... und konvertieren die vorhandenen Tests.
  
  
  
  • ... sollte natürlich weiterhin funktionieren, und wir möchten, dass dies eine "stille" Einstellung ist, so dass es (noch) keine Notwendigkeit gibt, Warnungen usw. auszugeben.
  
  
  • wir müssen daher die Tests für ... Muster beibehalten
  
  
  • Ich denke, der Weg, dies zu tun, besteht wahrscheinlich darin, den Lexer zu ändern, indem man das DotDotEquals Token ( hier ist das vorhandene DotDotDot ) hinzufügt und dann den Parser so ändert , dass er überall DotDotEquals akzeptiert jetzt DotDotDot akzeptieren ( Beispiel )
  
  
  • ripgrep DotDotDot ist dein Freund hier ;)
  
  
• ... in Ausdrücken war nie stabil, also können wir das einfach auf ..= ändern und die ältere Unterstützung beenden
  
  
  
  • Um nett zu Menschen in freier Wildbahn zu sein, könnten wir eine Verfallsphase durchlaufen, aber ich bin mir nicht sicher, ob das notwendig ist (Gedanken?)
  
  

Nur um zu beachten, dass bei der Implementierung die Syntax extern fn foo(a: u32, ...) nicht in ..= geändert werden sollte 😆

Ich bin versucht, es zu nehmen, da es wie ein netter erster Schritt in den Code aussieht, aber ich werde in den nächsten 2 Wochen nicht viel Zeit haben, also wenn jemand es abholen möchte, zögern Sie nicht!

Ich persönlich bin eher für ..^ als für ..= , da a operator= b für einige Betreiber bereits ein Alias ​​für a = a operator b . ^ hingegen wird viel weniger verwendet, nur für XOR, also sollte es weniger Verwirrung stiften.

.. liefert einen anderen Typ als der Typ des linken und rechten Operanden dafür, also sehe ich das für ..= nicht als Problem. Der Kontext hilft auch, den Zweck des Operators zu identifizieren. Etwas wie += gibt () sodass es als eigene Anweisung erscheinen kann, normalerweise in einer eigenen Zeile. Während ..= InclusiveRange zurückgibt, erscheint es als Ausdruck in anderen Anweisungen. Außerdem sieht es wie oben erwähnt aus, als hätte ..^ mehr mit Potenzierung als mit einem Bereich zu tun.

@Xaeroxe ^ hat in Rust nichts mit Exponentiation zu tun (obwohl es in anderen Sprachen als solche verwendet wird), während += , -= , *= alle gibt es in Rust. Tatsächlich existiert sogar ^= .

Aber idk, es ist auch in Ordnung, ..= zu haben.

Können wir die Bibliotheksstruktur jetzt stabilisieren, da #42134 zusammengeführt wurde? Ich denke, wir sollten warten, bis sich die Syntax stabilisiert hat, bevor wir das stabilisieren, obwohl es, wie ich bereits sagte, hilfreich wäre, die Struktur früher zu stabilisieren.

@clarcharr Ich glaube, wir sind zu dem Entschluss gekommen, diese Struktur sowie die ..= Syntax zu stabilisieren, also brauchen wir nur einige PRs, um dies tatsächlich zu tun.

EDIT: Woops, da lag ich falsch. Wir implementieren es im Compiler, die Stabilisierung der Syntax muss warten, bis die letzte Kommentarperiode abgelaufen ist. Ich denke, wir sollten die Struktur jetzt stabilisieren, aber das ist auch nicht meine Entscheidung.

Ich habe schon vor langer Zeit aufgehört, dem Thema zu folgen, als es mir so vorkam, als würde ... einen Konsens erzielen. ..= scheint mir nur peinlich, da es auf den ersten Blick wie eine Affektiertheit aussieht.

Aber viel wichtiger, ich glaube nicht, dass dieses Bikeshedding wichtig genug ist, um die aktuelle Pattern-Syntax zu ändern.

diese Syntax ist scheiße!
= Bedeutung der Zuweisung haben, auch in +=, -=, *= Modell, aber ..= geht es darum, etwas zu bekommen. so verwirrt und hässlich.
wie Array-Index bei 0 beginnen, '...' ist gut und schön, die Leute werden sich daran gewöhnen.

@zengsai
..= ist konzeptionell von Operatoren wie == und <= , die bereits in Rust existieren und auf Gleichheitsvergleiche hinweisen, nicht auf Zuweisungen.

(dh 1..=5 ist die Abkürzung für "Bereich über Werte 1 <= x <= 5 " im Gegensatz zu 1..5 was "Bereich über Werte 1 <= x < 5 " bedeutet)

EDIT: Es geht auch nicht darum, sich daran zu gewöhnen, sondern darum, was es schwieriger ist, falsch zu lesen oder zu tippen, wenn Sie müde oder abgelenkt sind. Off-by-One-Fehler wie diese sind bekanntermaßen fußgewehrartig.

Ich habe tatsächlich aus Versehen ... eingegeben, als ich .. meinte. Zum Glück ziele ich immer auf stabiles Rust, damit der Compiler es erwischt hat. (Ich kann mich jedoch nicht erinnern, ob es ein Muskelkrampf oder ein Muskelgedächtnis war, vorausgesetzt, ich wollte eine Pseudo-Ellipse eingeben, weil ich viel Sachbuch schreibe.)

@zengsai ... ist zu subtil, sieht zu ähnlich aus wie ..

Es ist wirklich ungewöhnlich, dass eine Sprache eine unterschiedliche Anzahl von Punkten hat, die unterschiedliche Dinge bedeuten

Das Entfernen einer Fußpistole ist wichtiger als ästhetisch ansprechend zu sein.

Neulinge: Ich habe ein TL;DR gemacht, weil dies ein sehr langer Thread ist. Sie können es hier lesen: https://github.com/rust-lang/rust/issues/28237#issuecomment -296310123

In Bezug auf "Off-by-One-Fehler wie diese sind bekanntlich fußgewehrartig", muss ich sagen: Tippfehler sollten nicht als Hauptgrund für diese Änderung verwendet werden.

Schauen Sie sich diesen Vergleich an, ".." und "..." vs "=" und "==", bedeutet das, dass wir eine andere Syntax für "==" finden sollten, um Tippfehler des Benutzers zu vermeiden? wenn "=" und "==" in Ordnung ist, warum können ".." und "..." das nicht?

Ich verfolge Rust-lang seit mehr als zwei Jahren. Ameise wurde es in vielen meiner privaten Projekte verwendet. Ich liebe es, aber diese Syntax hat mich wirklich unwohl fühlen lassen. nicht nur das ästhetisch ansprechende, es beeinflusst auch die Schreib- und Leseflüssigkeit von Code.

@zengsai nach meinem Verständnis geht es nicht in erster Linie darum, Code zu _schreiben_, sondern um Code zu überprüfen, zu lesen und zu verstehen. Wenn Sie nicht danach suchen, können Sie .. leichter übersehen als ... als Einzelfehler, während ..= definitiv mehr auffällt und gewonnen hat habe dieses Problem nicht.

Ich bin mir nicht sicher, ob mir die ..= Syntax auch aus ästhetischer Sicht gefällt, aber ich kann sehen, woher alle kommen, wenn .. und ... sehr ähnlich gelesen werden.

@zengsai Weil = vs. == eine Lösung hat, die für .. vs. ... nicht verfügbar ist.

Sicher, Sie können = und == in C verwechseln ... aber das ist eine anerkannte Waffe und modernere Sprachen wie Python und Rust haben das gelöst:

1. Es ist ein Fehler, wenn Sie if x = y statt if x == y (Dies ist der Fix, den Rust und Python gemacht haben)
2. Als ich versehentlich x == y; statt x = y; eingegeben habe, erhalte ich eine Warnung über einen Ausdruck, der keine Wirkung hat.

Es gibt keine Möglichkeit für den Compiler zu erkennen, dass eine .. vs. ... Verwechslung faul , geschweige denn falsch ist.

@zengsai .. und ... werden zu Typen ausgewertet, die dieselben Merkmale implementieren und im Wesentlichen austauschbar verwendet werden können (dies ist beabsichtigt). Das Aus-von-einem-Fehler ist ein sehr reales Problem.

Ich möchte klarstellen , dass ich diese Syntax auch hasse, so sehr, dass ich .. und Ausdrücke und ... in Muster ist "unhaltbar"; Tatsächlich denke ich, dass es besser ist, die Verbindung zu trennen als diese Syntax.

Aber es ist klar, dass wir uns darüber nie einig werden werden, dass es in diesem Thread keine neuen Argumente gibt und dass die Mehrheit der aktiv investierten Benutzer (wie auch der Rest des Sprachteams) diese Änderung befürworteten. Also stehe ich beiseite, damit wir das Problem lösen können.

Wenn es meiner Erfahrung nach ein Trost ist, brauchen die meisten Anwendungsfälle diese Funktion nie wirklich, und daher wird sie nicht überall in Ihrem Code auftauchen.

Eigentlich bin ich immer noch sehr unglücklich darüber, ... in Mustern abzulehnen, und ich werde im Grunde nur die Zähne zusammenbeißen, damit dieses Problem gelöst werden kann. Das gesamte lang-Team ist sich einig, dass es eine schreckliche Warze wäre, sowohl .. als auch ... Ausdrücke zu haben, die dazu führen würden, dass einige Benutzer Stunden damit verbringen, ein völlig stilles Tippfehlerproblem zu beheben.

Der Rest des Lang-Teams ist der festen Überzeugung, dass eine Trennung zwischen Ausdrücken und Mustern inakzeptabel ist, und obwohl ich nicht zustimme, haben wir alle unsere Argumente vorgebracht und ich denke nicht, dass es gesund ist, für immer in einer Pattsituation zu sein.

@ssokolow Entschuldigung, ich kann dir immer noch nicht zustimmen. Compiler kann Sie vor dieser Art von Tippfehler warnen, aber was ist, wenn Sie "x=5" eingeben, wo es "x=6" sein sollte?

Compiler ist nicht der perfekte, um Tippfehler zu vermeiden, der Programmierer ist es.

Wenn diese Änderung keine Nebenwirkungen hat, stimme ich voll und ganz zu. aber dadurch verliert die Sprache an Ästhetik, Schreib- und Leseflüssigkeit, die sich nur meiner persönlichen Meinung nach nicht lohnt.

Der heutige Rost stößt bereits auf Lese- und Schreibprobleme, je ungewöhnlicher und kontraintuitiver die Syntax, desto mehr Lernkurve, macht es nicht zu einem anderen Perl.

@Withoutboats Wir streiten damit, weil wir es lieben. Vielleicht kommt dieses Argument zu spät und kann nichts ändern, nur...

@zengsai

Es gibt sicherlich Kompromisse, aber ich habe den Eindruck, dass wir uns nie auf die beste Balance zwischen diesen einigen werden.

Ungeachtet des persönlichen Geschmacks sehe ich ..= als einen winzigen Preis, den es zu zahlen gilt, um zu vermeiden, dass viel Zeit verschwendet wird, um Fehler aufzuspüren.

(Mein Schwerpunkt liegt auf dem UI/UX-Design und eine der wichtigsten Regeln, die sie Ihnen beibringen, ist, dass Sie darauf abzielen sollten, die Fehlerwahrscheinlichkeit umgekehrt proportional zu dem Schaden und/oder der Zeit zur Behebung zu machen, die er verursacht. )

Meiner kleinen Meinung nach ist 5 vs. 6 viel offensichtlicher zu sehen als .. vs ... .

@zengsai Ich wenn Sie zum IRC-Kanal

@daiheitan Dies ist eine normale Mitteilung. Wenn sie Ihnen nicht gefällt, empfehle ich Ihnen, das

Als ich Rust zum ersten Mal ansah, war ich wirklich überrascht über die Syntax von .. . (1..10).sum() ist... die Summe der ganzen Zahlen von 1 bis 9? Wenn Sie diese Syntax einem Neuling präsentieren und ihn fragen, was sie bedeutet, wird er wahrscheinlich erwarten, dass sie von 1 bis 10 geht. Und er hat Recht, da Sie erwarten würden, dass symmetrische Syntax symmetrisch ausdrückt reicht. Warum sollte die 1 enthalten sein, aber nicht die 10?

Das Hinzufügen einer weiteren asymmetrischen Form ..= für einen symmetrischen Bereich macht dies optisch noch inkonsistenter. Man könnte sich fragen, warum die linke Seite kein = braucht, um inklusiv zu sein, also wäre es =..= für inklusive Bereiche auf beiden Seiten.

Etwas wie die Swift-Syntax ( ..< für exklusive und ... für inklusive) würde diese Probleme vermeiden und die Lesbarkeit verbessern. Sie können die Bedeutung leicht erraten, selbst wenn Sie noch nie mit der Sprache vertraut sind, sodass Sie sich eine Sache weniger merken müssen. Ich hätte erwartet, dass so etwas gewählt wird, vor allem in Anbetracht von Rusts Vorstoß in Richtung Newcomer-Freundlichkeit.

@rkarp In gewissem Maße liegt das wahrscheinlich an einer bereits bestehenden Voreingenommenheit.

Zum Beispiel gibt es viel Python-Einfluss in Rust und Python verwendet die gleiche Art von halboffenen Bereichen. (dh Pythons range(1, 5) oder myList[1:5] beide das gleiche Verhalten wie Rusts 1..5 )

Die Begründung dafür war in Python damit verbunden, dass es nur eine Syntax gab und eine halboffene Syntax es einfacher machte, Dinge wie head, tail = myList[:pivot], mylist[pivot:] zu tun.

Da Rust 1.0 bestanden hat, gibt es jedoch ziemlich strenge Regeln, um bestehenden Code nicht zu brechen. .. für exklusive Außenmuster und ... für exklusive Innenmuster müssen gültig bleiben.

..= funktioniert, weil Sie .. (exklusiv) und ..= (inklusive) überall akzeptieren und ... als veraltetes Synonym für .. bei Mustern.

Nur zu sagen, ..= als Token zu haben, ist technisch gesehen eine inkompatible Änderung, da sie :tt Regeln in Makros betrifft. Wäre wahrscheinlich nicht problematisch, aber Sie sollten sichergehen, dass dies nicht jemand tut, da dies auch eine stille Änderung sein kann. (die Alternative besteht darin, .. /* why not */ = zuzulassen, was meiner Meinung nach keine gute Idee ist)

@ssokolow Technisch gesehen ist es ein a = 2 ist ein Ausdruck, der () zurückgibt, und if erwartet bool , also sind sie eindeutig inkompatibel.

Die Regeln ändern sich langsam. Technisch gesehen handelt es sich bei ..= um 3 Token, bei denen die ersten 2 kein Leerzeichen hinter sich haben.

@eddyb : Ich gebe zu, ich verstehe es nicht ganz. Gibt es eine Möglichkeit, ein neues Token einzuführen, ohne dass dies beeinflusst wird, wie :tt es analysiert?

Dieser Code meldet derzeit "Regel 2" und "Regel 4". Diese Änderung, wenn ich sie richtig verstehe, würde sie in "Regel 2" und "Regel 5" ändern.

macro_rules! ex {
    ( . . )   => { "Rule 1: . ." };
    ( .. )    => { "Rule 2: .."};
    { . . = } => { "Rule 3: . . = " };
    { .. = }  => { "Rule 4: .. = " };
    { ..= }   => { "Rule 5: ..=" };
}

macro_rules! show {
    ( $($t:tt)* ) => { println!("{}", ex!($($t)*)) };
}

fn main() {
    show!(..);
    show!(..=);
}

Nein, es handelt sich um eine Änderung der Definition von Token. @jseyfried kann die Konsequenzen besser erklären.

Technisch gesehen ist es ein Typfehler in Rust, kein Parse-Fehler. a = 2 ist ein Ausdruck, der () zurückgibt, und if erwartet bool, sodass sie eindeutig inkompatibel sind.

@xfix Danke. Ich habe beim letzten Mal nicht richtig aufgepasst und bin es immer noch nicht ganz gewohnt, in ausdrucksorientierten Sprachen zu denken.

Ich habe meinen Kommentar angepasst.

Ich mag die Syntax von ..= und bin dagegen, ... in Mustern abzulehnen. Wenn wir Angst vor einem Tippfehler haben, können wir immer die Struktur RangeInclusive { start, end } anstelle von ... oder ..= für die Kurzschrift verwenden.

Mögliche Mehrdeutigkeit, die ich gerade erkannt habe:

if let 5..=x { ... }

@clarcharr Sieht jedoch so aus, als würde es nicht kompiliert.

rustc 1.17.0 (56124baa9 2017-04-24)
error: unexpected token: `=`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |             ^^

error: aborting due to previous error

@clarcharr @kennytm
Nachdem wir ..= als einen Operator eingeführt haben, wäre der Fehler:

error: expected one of `::` or `=`, found `{`
 --> <anon>:3:13
  |
3 |     if let 5..=x {
  |                  ^

error: aborting due to previous error

Genau wie jetzt mit let x=10; if let 5..x {}

Diese "Mehrdeutigkeit" würde also nicht kompiliert und wäre daher nicht mehr als if let 5..x {} .

@Boscop Der Punkt ist, wenn wir derzeit 5.. als Muster wie Some(5) , dann wäre if let 5.. = x let Some(5) = x ähnlich, und letzteres kompiliert. Mein Kommentar zeigt, dass 5.. kein Muster ist, daher besteht kein Kompatibilitätsrisiko von if let für die Einführung von ..= .

Wenn wir diese Funktion einführen und sowohl ..= als auch .. in Mustern zulassen, sollte if let 5..=x immer if let 5.. = x und es sollte kompilieren: if let (single expression) macht keinen Sinn, daher glaube ich nicht, dass es Mehrdeutigkeiten gibt.

@kennytm, also haben wir beide für 2 verschiedene Mehrdeutigkeiten gezeigt, dass sie nicht kompiliert werden. (Es war nicht klar, welche er meinte. Es war irgendwie zweideutig, heh.)

@daboross Wie kennytm sagte, ist 5.. kein Muster und wird auch jetzt nicht kompiliert. Und das ändert sich auch nicht, wenn wir ..= als Operator hinzufügen. Es gibt keine Zweideutigkeit. Wichtig ist, dass ..= jetzt nicht als ein Operator geparst werden kann, aber sobald wir es als einen Operator geparst haben, gibt es keine Mehrdeutigkeit.

5.. ist kein derzeit gültiges Muster, noch haben wir halbgeschlossene Intervallmuster. Abgesehen davon wird das Fehlen von halbgeschlossenen Intervallmustern oft als Quelle von Inkonsistenzen im Vergleich zu Bereichsausdrücken angesehen und kann auch für Muster implementiert werden. Wir könnten auch die Möglichkeit hinzufügen, eine Seite des Intervalls in Mustern später wegzulassen, zB für erschöpfende Ganzzahl-Matches.

Während die Beobachtung von @clarcharr nicht unbedingt auf Mehrdeutigkeiten hinweist, wenn die aktuelle Grammatik berücksichtigt wird, ist es sicherlich eine Mehrdeutigkeit, wenn potenzielle zukünftige Erweiterungen in Betracht gezogen werden, die mit dem Vorschlag in Konflikt stehen könnten, ..= für Muster zu verwenden.

Vor diesem Hintergrund würde ich vorschlagen, hier ein anderes Symbol zu verwenden. ^ scheint mir ziemlich in Ordnung zu sein, da es nur in einem Ausdruckskontext verwendet wird, der derzeit IIRC ist.

(Dies ist ein weiterer Grund, warum ich es für eine gute Idee halte, die Struktur jetzt und die Syntax später zu stabilisieren.)

@nagisa es gibt keinen Konflikt bezüglich if let wenn das Token ..= hinzugefügt wird, bevor das RangeFrom-Muster unterstützt wird. Man könnte ein Leerzeichen zwischen .. und = einfügen, um die Mehrdeutigkeit zu verdeutlichen, genau wie x <- y (Platzierung in) vs. x < -y (weniger als + negativ).

(Da ^ der exklusive -oder-Operator ist, finde ich es ironisch, ..^ für den inklusiven Bereich zu verwenden)

In den Tausenden von Bereichen, die ich geschrieben habe, von denen einige vollständig geschlossen sind, vielleicht sogar ein oder zwei halboffen verkehrt herum, sehe ich immer noch keine Notwendigkeit für zusätzliche Syntax. 1..(n+1) ist nicht so schwer zu schreiben.

Das funktioniert nicht für end = T::max_value().

Am 29. Mai 2017 um 16:33 Uhr schrieb "Diggory Hardy" [email protected] :

In den Tausenden von Bereichen, die ich geschrieben habe, einige davon vollständig geschlossen,
vielleicht sogar ein oder zwei halb aufgedreht verkehrt herum, ich weiß es immer noch nicht wirklich
sehen Sie die Notwendigkeit für zusätzliche Syntax. 1..(n+1) ist nicht so schwer zu schreiben.

—
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/rust-lang/rust/issues/28237#issuecomment-304662258 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
.

Ich würde jedoch eine Methode auf halbgeschlossenen Bereichen gegenüber ..= bevorzugen.

Am 29. Mai 2017 um 16:35 Uhr schrieb "Simonas Kazlauskas" [email protected] :

Das funktioniert nicht für end = T::max_value().

Am 29. Mai 2017 um 16:33 Uhr schrieb "Diggory Hardy" [email protected] :

In den Tausenden von Bereichen, die ich geschrieben habe, einige davon vollständig
geschlossen, vielleicht sogar ein oder zwei halb offen verkehrt herum, ich immer noch nicht
sehen wirklich die Notwendigkeit für zusätzliche Syntax. 1..(n+1) ist nicht so schwer
schreiben.

—
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/rust-lang/rust/issues/28237#issuecomment-304662258 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AApc0ipynL_qrZqUBldOJOX046RNY2H_ks5r-skwgaJpZM4F4LbW
.

Ich wünschte wirklich, wir würden die Merkmale und Typen bereits mit einer Methode zu ihrer Konstruktion stabilisieren, da ich mir ziemlich sicher bin, dass darüber keine Meinungsverschiedenheiten bestehen. Bitte lassen Sie nicht zu, dass Bikeshedding über die Syntax die Stabilisierung der Kernfunktionalität selbst aufhält.

Das funktioniert nicht für end = T::max_value().

Möchten Sie wirklich über 2^64 Werte oder sogar 2^8 Werte iterieren? Wenn Sie nur über die letzten paar Werte von zB u32 iterieren möchten, ist es oft einfacher, einen innerhalb der Schleife hinzuzufügen. Und wenn Sie aus irgendeinem unklaren Grund wirklich zu 2^B-1 iterieren möchten, können Sie immer if i == END { break; } am Ende einer Schleife festhalten.

Nur weil unsere Standard-Ganzzahlen ohne Vorzeichen 2^32- oder 2^64-Werte unterstützen, heißt das nicht, dass der höchste darstellbare Wert sehr oft verwendet wird. Und wenn Sie etwas mit u8 machen, vergessen Sie nicht, dass es für die CPU wahrscheinlich sowieso einfacher ist, u32 für einen Zähler zu verwenden.

Aber selbst wenn ich keine Notwendigkeit für die Syntax des Generators mit geschlossenem Bereich sehe, kann ich die Argumente des Teams für die Änderung nicht widerlegen. Naja :/

Wie wäre es, wenn diese vier Optionen für alle Inklusivleistungen umfassen?

1...10
1>..10
1..<10
1>.<10

Ich kann mir vorstellen, dass man in der Lage sein sollte, ohne weitere Erklärung zu verstehen, was sie bedeuten, da sich die Ungleichungsoperatoren vom Kindergarten an in den Kopf gehämmert haben ... aber keine Ahnung, ob dies auf andere Weise schmerzhaft wäre.

Alternativ könnten wir die Ungleichungen vertauschen:

1...10
1<..10
1..>10
1<.>10

... nur damit der letzte nicht wie ein wütender Cartman aussieht.

@vegai und was ist mit der bestehenden a..b Syntax, die sicherlich nicht entfernt wird? Nein, ich glaube nicht, dass der Vorschlag neuer Syntaxoptionen alles lösen wird.

Hmm, es wurden also zwei "potenzielle Mehrdeutigkeiten" aufgeworfen:

• if let 5..= x -- wie bereits erwähnt, ist dies jetzt nicht wirklich eine Zweideutigkeit, aber es könnte irgendwie sein. Andererseits tritt diese Art von Mehrdeutigkeit häufig auf und wird vom Tokenizer adressiert. Das heißt, wenn wir ..= als Token in unserem Parser betrachten, ist dies nicht mehrdeutig, selbst wenn wir in Zukunft 5.. Muster hinzufügen; Sie müssen lediglich ein Leerzeichen zwischen .. und = schreiben (zB let 5.. = x ).
• die Mehrdeutigkeit in Bezug auf Makroregeln. Dies ist in der Tat schmerzlich und bedauerlich und einer der Gründe, warum wir für "Makros 2.0" zu einem anderen System übergegangen sind, bei dem wir es vermeiden, dem Endbenutzer den Satz von "zusammengesetzten Token" zugänglich zu machen.
  
  
  
  • am Ende können wir macro_rules! Back-Compat über einen speziellen Code verarbeiten, falls erforderlich; Jedenfalls denke ich, dass man diese Art von Problemen nicht vermeiden kann, außer durch die Verwendung von ... .
  
  

Vor der Stabilisierung inklusiver Bereiche sollte auch das Problem #42401 imo behoben werden, da die Korrektur nach der Stabilisierung ein Breaking Change wäre.

@est31 guter Punkt, das habe ich der Checkliste am

Checked str Slicing ist selbst instabil und die Behebung dieses Problems blockiert keine Inklusivbereiche.

Oh, @nagisa hat Recht, es hat nichts mit der Bereichssyntax zu tun. Kannst du es wieder vom Kopf entfernen? Mein Fehler. Der Fehler liegt eher in der Implementierung von get und wird daher von der Funktion str_checked_slicing bewacht:

    impl SliceIndex<str> for ops::RangeToInclusive<usize> {
        type Output = str;
        #[inline]
        fn get(self, slice: &str) -> Option<&Self::Output> {
            if slice.is_char_boundary(self.end + 1) {
                Some(unsafe { self.get_unchecked(slice) })
            } else {
                None
            }
        }
    [...]

ENTFERNT

Ein weiteres Kontrollkästchen-Update: PR https://github.com/rust-lang/rust/pull/42134 hat die https://github.com/rust-lang/rfcs/pull/1980-Optimierung angewendet

Bump: Können wir zumindest die Strukturen für 1.20 stabilisieren?

Wie wäre es, wenn wir uns den berühmten go-to-Operator aus C++ für die inklusive Bereichssyntax ausleihen? 😛

@nikomatsakis und @rust-lang/libs (ich weiß nicht, wie ich das taggen soll), wie würdest du dich fühlen, wenn ich eine PR einreichen würde, die die Strukturen auf ein anderes Tracking-Problem verschiebt, damit wir über die Stabilisierung für sie sprechen können? dort? Ich denke, dass dies eine gute Möglichkeit wäre, diese früher zu stabilisieren, während wir auf die Implementierung/Abstimmung der neuen Syntax warten.

cc @rust-lang/libs (nur Personen in einem Team können ihre oder andere Teams markieren)

Danke, @eddyb!

@clarcharr Basierend auf https://github.com/rust-lang/rust/pull/42275#discussion_r119211211 vermute ich, dass es dankbar wäre.

Bin ich zu spät für den Zug für den Syntaxvorschlag?
Der Strom sieht so aus, als würde jemand versuchen, dem Slice den Wert zuzuweisen.

for i in a..b {} // [a..b) 
for i in a..+b {} //[a..b] 
for i in a-..b {} //(a..b) 
for i in a-..+b {} // (a..b]

Diese Syntax würde es unmöglich machen, in Zukunft irgendwelche Add Implementierungen für Bereiche hinzuzufügen. Ich weiß nicht wirklich, ob das ein Problem ist, da ich nicht wirklich sicher bin, was eine Add Implementierung bewirken würde.

Stimmen Sie dem nachgestellten Plus zu. In Präfix geändert.

Da a.. , ..b und .. gültige Konstrukte in Rust sind, erzeugt dies immer noch Mehrdeutigkeiten bei mathematischen Operationen :/

a... / a..= / a..+ wäre aber nicht gültig, oder? Da ein unbegrenzter Bereich einen Endpunkt einschließt, ist es nicht wirklich sinnvoll.

Ich würde mir keine Sorgen um Add , es scheint nicht so zu sein, als ob es eine allzu häufige Sache wäre, mit Bereichen zu tun, und wenn Sie wollten, könnten Sie (x..+y) + z ?

Edit: egal, hab gerade gemerkt was du meinst. Es wäre a..+b , das wäre mehrdeutig, oder? Denn im Moment bedeutet es a.. + b .

@daboross Nicht zu sagen, dass dies eine gute oder schlechte Idee ist, aber diese Implementierung (oder eine Variation davon) könnte etwas sein, was wir in Zukunft für Bereiche wünschen:

impl<T> Add<T> for RangeFrom<T> where T: Add<T> {
    type Output = RangeFrom<T>;
    fn add(self, rhs: T) -> RangeFrom<T> {
        (self.start + rhs)..
    }
}

Dieses spezielle Impl kann eine gute Idee sein oder auch nicht, aber ich habe nicht lange gebraucht, um es als möglichen zukünftigen Anwendungsfall zu entwickeln. Ich denke, es wäre eine schlechte Idee, die Möglichkeit auszuschließen, dass dies oder so etwas aufgrund bestehender Syntaxentscheidungen hinzugefügt wird.

Meine andere Sorge ist, dass der Sinn von ... besteht, die Wahrscheinlichkeit von schwer zu erkennenden Tippfehlern zu minimieren und es den Eltern zu ermöglichen, zwischen zwei verschiedenen Bedeutungen der abstrakten a..+b unterscheiden, die sich so anfühlen würde wieder in diese Richtung gehen.

Darüber hinaus habe ich noch keine solide Begründung für a-..b und a-..+b jenseits von "wäre es der Vollständigkeit halber nicht schön", während die aktuellen .. und die vorgeschlagenen ..= beide haben bekannte, gültige Gründe.

Sie können dafür nicht + da dies die Ausdruckssyntax mehrdeutig macht.

BEARBEITEN: Obwohl ich vermute, dass es die Implementierung inklusiver Bereiche vollständig in der Bibliothek ermöglichen würde, da Sie am Ende nur eine Implementierung von <Range as Add<{integral}>>::Output = InclusiveRange .

Ich kann die Variante ..! vorschlagen. Es hat einen produktiven Reim mit .. und legt zusätzlichen Wert auf den letzten Punkt, um ihn auffälliger zu machen.

Natürlich würde es mit dem Operator ! kollidieren, aber ehrlich gesagt konnte ich mir die Situation nicht vorstellen, in der man ! in einen gebundenen Unterausdruck einfügen müsste.

..! hat ein Problem mit der Intuitivität. Ein Neuling, der noch nicht mit der Syntax vertraut ist, könnte ..! leicht als "bis zu, aber nicht..." missverstehen.

Es kollidiert auch mit der Syntax für "Bereich bis zum bitweisen Komplement von..." (was es in eine Situation bringen würde, die der Verwendung von + ähnelt).

Zustimmen. Aber andererseits kann ..= auch als einer der Zuweisungsoperatoren fehlinterpretiert werden.

Was würden Sie zuweisen, wenn dies ein Zuweisungsoperator wäre?

Basierend auf dem Vorschlag von @snuk182 :

a...b // [a; b] shorthand for RangeIncusive
a..-b // [a; b) new Range shorthand 
a..b // [a; b) old Range shorthand exists for compatibility

Ich bezweifle, dass wir andere Kombinationen brauchen. In jedem Fall kann es später hinzugefügt werden:

a-..b // (a; b]
a-.-b // (a; b)  

Obwohl die letzte Option etwas seltsam aussieht. ^_^

Bitte hören Sie auf, eine Syntax vorzuschlagen, die einen unären Operator enthält, zB a..-b , a..!b , a..*b , a..&b oder a?..b akzeptiert.

..! hat ein Problem mit der Intuitivität. Ein Neuling, der noch nicht mit der Syntax vertraut ist, könnte es leicht missverstehen..! "bis zu, aber nicht..." bedeuten

..= hat das gleiche Problem mit der Intuitivität. Jeder, der ein = sieht, erwartet eine Zuneigung oder einen Vergleich. Ich erkenne an, dass diese Syntax das Unterscheidbarkeitsproblem vollständig löst, denn jedes Mal, wenn ich ..= sehe, kann ich nicht verhindern, dass ich mich frage, was dieses Gleichheitszeichen hier macht.

Die einzige vorgeschlagene Syntax, die sowohl ziemlich intuitiv als auch mit der aktuellen Syntax konsistent ist, ist ... . Aber es scheint, dass das Schiff gesegelt ist.

Neueinsteiger müssen sowieso häufig in den Dokumenten nachsehen. Sogar mit ... würden sie sich die Dokumente ansehen. Dies ist nicht vermeidbar. Aber ..= hat eine nette Mnemonik ( up to und equal to ), damit sie nicht häufig in den Dokumenten für diesen Operator nachsehen müssen.

Was wäre, wenn der Operator ... so bleiben würde, wie er ist, aber stattdessen den Operator .. in ..⎵ ändern würde, dh zwei Punkte und ein Leerzeichen (ich musste das '⎵ ' da ein normales Leerzeichen auf dieser Webseite nicht angezeigt würde). Es wäre der einzige Ort in der Sprache, an dem Weißraum wichtig ist. Es wäre auch eine bahnbrechende Änderung, da sich jeder Code wie a..b beschweren würde, dass es keinen Operator wie .. , und raten, mindestens ein Leerzeichen nach den Punkten hinzuzufügen. Ich denke, dass der Raum sie visuell deutlich genug macht:

a.. b
a...b

@tommit Ich glaube, das wäre keine gute Idee, um ehrlich zu sein.

Der Operator ist derzeit bezüglich Leerzeichen recht flexibel, zum Beispiel: a..b und a .. b sind gleich. Dies dient wahrscheinlich dazu, es mit anderen Operatoren wie a+b und a + b Einklang zu bringen. Diese tun natürlich dasselbe und ermöglichen es den Leuten, unterschiedliche Syntaxstile zu verwenden. Das ist gut so, wenn Sie mich fragen!

Darüber hinaus stimmt die Notation ..= mit den Notationen <= und >= überein (die auch als _inklusive_ betrachtet werden).

Es ist immer gut zu prüfen, welche anderen Möglichkeiten es gibt, aber das ist wahrscheinlich nicht die richtige Lösung.

Zustimmen. Im Vergleich zu <= und >= ..= sieht

Übrigens, wenn Sie ein Fan von ... oder einfach nicht mögen, wie ..= aussieht, dann wäre die Kompromisslösung, eine Schriftart mit Programmierligaturen zu verwenden, wie FiraCode mit spezieller Ligatur für ..= , die ... , oder sogar etwas Seltsames wie ⩷, ⩦ oder ≔.

Breaking Change an allen vorhandenen Rostcodes unter Verwendung von Bereichen ... tot bei der Ankunft,
Verzeihung. Wenn jemand einen wirklich ernsthaften abwärtskompatiblen Vorschlag dazu hat
die Bedenken ansprechen, die geäußert wurden, und es wurde nicht diskutiert
schon, lass es uns hören, aber lass uns das zumindest als Standard belassen, ja?
Dieser Thread ist voller Fahrradschuppen und das Team hat sich schon so entschieden
das ist eine hohe Messlatte.

Auf jeden Fall scheint es immer noch eine Menge Fahrradschuppen über die eigentliche Syntax zu geben. Ich habe #43086 eingereicht, um zumindest die Structs und Traits und Impls zu stabilisieren, damit die Kernfunktionalität genutzt werden kann (es scheint Nachfrage zu geben, siehe Kommentar von @retep998 oben).

Der Elefant im Raum ist, dass .. hier aufgrund seines symmetrischen Aussehens, aber seiner asymmetrischen Bedeutung tatsächlich das eigentliche Problem ist. Das "Richtige" würde wahrscheinlich bedeuten, es abzulehnen, aber dazu besteht kein Wille, da es bereits von so viel Code verwendet wird.

Das vollkommen konsistente ... (symmetrisches Aussehen, symmetrische Bedeutung) abzulehnen ist der einfache Ausweg, aber auf Kosten des Hinzufügens eines weiteren inkonsistenten Operators in ..= . Es scheint, als würde man schlechtes Design hinzufügen, um vorheriges schlechtes Design zu umgehen.

Aufgrund dieser doppelten Inkonsistenz gibt es noch ein weiteres Problem: Es gibt keine gute Möglichkeit, die letzten beiden verbleibenden Inklusivitätsvarianten (beidseitig exklusiv und nur auf der linken Seite exklusiv) hinzuzufügen. Da sowohl .. als auch ..= bereits ein implizites = auf der linken Seite hätten, müssten wir das irgendwie negieren, möglicherweise mit einem < . Sie müssten also etwa so aussehen:

• <..= für (a; b]
• <.. für (a; b)

Viel Glück beim richtig erraten, was diese als Neuling bedeuten. Daher würden sie wahrscheinlich (zu Recht) nie als hinzugefügt betrachtet werden.

Wenn .. nicht so fest verankert war oder gar nicht existierte, scheint es nicht so schwer, für all dies von Grund auf ein einheitliches Design zu entwickeln, zum Beispiel:

• .. (oder ... ) für [a; b]
• ..< für [a; b)
• <.. für (a; b]
• <..< für (a; b)

Ich habe das Gefühl, dass die letzten beiden Varianten irgendwann nützlich sein könnten, sollten wir uns wirklich so schnell den Weg dorthin versperren? Auf jeden Fall ist der einzige gute Grund, ..= veralteten .. vorzuziehen, das Brechen von viel weniger altem Code, aber es wäre bestenfalls ein notwendiges Übel, nichts, was man feiern könnte.

_Edit: Ein Beispiel und einige Kommentare für mehr Klarheit hinzugefügt._

Ich stimme @rkarp zu, dass .. hier das eigentliche Problem ist, nicht ... oder ..= . Die asymmetrische Bedeutung ist besonders schlecht , wenn man , dass andere (populäreren) Sprachen tatsächlich eine symmetrische Bedeutung tun assign. Sowohl Kotlin, Ruby als auch Haskell betrachten 5 beispielsweise im Bereich von 3 bis 5. Auch mathematische Arbeiten scheinen dies zu befürworten. Das Schlimmste hier ist, dass Anfänger keine Chance haben, das Verhalten von 3..5 in Rust zu erraten: Sie würden entweder entscheiden, dass 4 und nur 4 ein Mitglied des Bereichs 3..5 ist (Iteration über die Punkte) oder dass beides 3 und 5 sind auch drin (Iteration über 'alles was wir sehen' und die Extrapolation der Punkte).

Ich bin jedoch anderer Meinung, dass es schwierig ist, dies zu ändern. Ich denke, der Vorschlag von @adelarsq könnte relativ schmerzlos implementiert werden. Als Referenz:

[1..4] // 1, 2, 3, 4
[1..4[ // 1, 2, 3
]1..4] // 2, 3, 4
]1..4[ // 2, 3

Jedes Vorkommen von x..y (ohne eckige Klammern) könnte in [x..y[ und eine Compiler-Warnung ausgeben. Nach einigen Releases könnte der Compiler es einfach ablehnen, "nackte" Bereichsnotationen zu kompilieren, und vielleicht sogar Tools anbieten, um automatisch in die neue Notation zu konvertieren.

https://github.com/rust-lang/rust/issues/28237#issuecomment -274216603 Das ist keine neue Idee und wir können sie aus den bereits erwähnten Gründen nicht verwenden.

Ich stimme absolut der Idee zu, dass wir, wenn wir die Sprache im Nachhinein von Grund auf neu entwerfen würden, die Syntaxen von exklusiven und inklusiven Bereichen gemeinsam betrachten möchten. Ich denke, dass ..= nicht der ideale Operator für einen inklusiven Bereich ist; es ist einfach die beste Option, die derzeit auf dem Tisch liegt. Aber den aktuellen exklusiven Bereichsoperator abzulehnen wäre übermäßig schmerzhaft und abschreckend für bestehende Rust-Benutzer und -Projekte.

Es gibt zahlreiche andere Vorschläge, die funktionieren ..@ vorgeschlagen gesehen, und x..@y scheint evokativ. Die Herausforderung besteht darin, etwas überzeugenderes als den aktuellen Vorschlag zu finden und gleichzeitig die Unklarheit zu bewahren.

Ich wollte den Kommentar von @ssokolow vor 2 Monaten als meine Lieblingsansicht der Symmetrie

• ..4 enthält Dinge < 4
• ..=4 enthält Dinge <= 4

Ich denke, wir brauchen nur den inklusiven Bereich, das ist einfacher.
Sie können jederzeit +1 oder -1 hinzufügen, um den Bereich zu ändern.
Und .. ist besser, weil .. einfacher ist als ... !

@AlexanderChen1989 Wie bereits in mehreren Beiträgen in diesem Thread erwähnt, ist dies nicht möglich, da das Ändern der Bedeutung von .. den vorhandenen Code

Außerdem ist es gar nicht so einfach. Vor allem +1 und -1 können einen ganzzahligen Überlauf/Unterlauf verursachen.)

Hier ist ein Beispiel, das in nightly funktioniert (über den alten Kandidaten für die Syntax für den inklusiven Bereich), wo...

• ...welche Schleife auch immer Sie zuerst einsetzen, wird bei Überlauf/Unterlauf in Debug-Builds in Panik geraten
• ... sie verhalten sich in Release-Builds völlig anders als beabsichtigt (dh "0 bis 0" wird 256 Mal iteriert und "0 bis 255" wird überhaupt nicht iteriert)

#![feature(inclusive_range_syntax)]
fn main() {
    let max = 255u8;
    let user_provided = 0u8;

    for x in 0...user_provided-1 {
        println!("(0 to 0, exclusive via 'inclusive - 1'): {}", x);
    }

    for x in 0..max+1 {
        println!("(0 to 255, inclusive via 'exclusive + 1'): {}", x);
    }
}

Seit der Entscheidung des Sprachteams wurden 8 Syntaxvorschläge für Dead-on- Arrival gemacht. Neulinge bitte den Thread lesen. Wir hatten sehr gute Gründe, die Entscheidungen zu treffen, die wir getroffen haben, versprochen.

IMHO sollte das OP aktualisiert werden, um darauf hinzuweisen, dass in diesem Thread keine Syntaxdiskussion mehr geführt werden sollte, und alle Vorschläge zur exklusiven Bereichssyntax (dh (a, b) und (a, b] Bereiche) sollten in einen anderen Thread verschoben werden.

Dies sollte nur über Dinge sprechen, die getan werden müssen, um den aktuellen Plan zu stabilisieren.

@clarcharr Ich habe eine meist einseitige Entscheidung getroffen und das zum OP hinzugefügt, gute Idee. Wenn das Geräusch anhält, würde ich dafür stimmen, den Thread zu sperren.

Hallo, ich bin neu und würde gerne anfangen an diesem zu arbeiten. Ich werde versuchen, den PR zu schreiben, um ..= als Synonym für ... in Mustern hinzuzufügen, ... in Ausdrücken veraltet zu machen und eine Fehlermeldung anzuzeigen, die besagt, dass die Syntax geändert wurde in ..= . Klingt das richtig?

@Badel2 cool. Ich habe tatsächlich angefangen - ich werde bald meinen Zweig pushen und ihn hier verlinken.

@durka, nur um das klarzustellen - bieten Sie an, @Badel2 von Ihrer Filiale aus fortfahren zu lassen? Könnten Sie sie im Rahmen der Impl-Zeitarbeit betreuen? Sie sind im Gitter-Kanal.

Ich stimme auch zu, dass das eigentliche Problem .. . Die günstigere Lösung besteht also darin, .. zugunsten von ..< verwerfen (nicht sofort zu ersetzen, sodass der vorhandene Code __nicht__ brechen würde) (es gibt keine Verwechslung zwischen a..<b und (a..)<b , da die .. irgendwann aufhören werden zu existieren).

@hyst329 Bitte lesen Sie die bereits erstellten Beiträge.

Der allererste Beitrag sagt in Fettdruck: "In diesem Thread sollte keine Syntaxdiskussion mehr geführt werden."

Abgesehen davon wurde das, was Sie beschreiben, hier bereits mehrfach von anderen vorgeschlagen, die die bestehende Diskussion nicht gelesen haben, und es gibt mehrere Gründe dafür, warum dies keine praktikable Option ist.

Tut mir leid, das ist nicht sehr konstruktiv, aber jedes Mal, wenn ich ..= sehe und versuche, mich daran zu erinnern, sieht es aus wie ein Zuweisungsoperator ähnlich wie += oder <<= . Es fühlt sich sehr verwirrend an, dass dies nicht der Fall ist. (Obwohl dies zugegebenermaßen aus dem Kontext gerissen wurde, zum Beispiel „erste Unterstützung für die ..= Syntax“ https://this-week-in-rust.org/blog/2017/10/03/this-week- in-rost-202/)

@SimonSapin Ich habe dieselbe Kritik oben konstruktiver geäußert und stattdessen ..^ : https://github.com/rust-lang/rust/issues/28237#issuecomment -304325663

Für mich ist ein großer Punkt, der für ..= spricht, die Konsistenz mit Swift (die ..< für exklusive und .. für inklusive Bereiche hat). Dadurch war ich mit der Wahl von ..= .

@SimonSapin Ich glaube nicht, dass es jemanden gibt, der damit vollkommen zufrieden ist. Das Problem ist, Hunderte von Kommentaren haben leider bestätigt, dass es keine bessere Alternative gibt.

Dieser Patch hat mich überzeugt, dass es besser ist, nichts zu tun, als die aktuelle Mustersyntax durcheinander zu bringen, nur um Randfälle abzudecken.

.. hat nur sehr wenige Anwendungsfälle in Mustern und Sie können immer darauf verzichten.

... kann in Ausdrücken, die sie wirklich erfordern, durch ein RangeInclusive oder ein (Bound<T>, Bound<T>) werden. Es ist ausführlicher, aber leicht zu verstehen.

@UtherII

...und ich war überzeugt, dass ... unhaltbar ist, als ich durch die Compiler-Meldung "You can't use Inclusive Range Syntax on Stable" vor einem subtilen Fehler gerettet wurde.

Es ist einfach zu einfach, versehentlich . einmal zu oft zu drücken (oder, angesichts der beteiligten Mechaniken, einmal zu wenig), wenn Sie mehrmals in schneller Folge drücken.

Ich habe die "Änderung, um ..= als Synonym für ... in Mustern zu akzeptieren und ..= in Ausdrücken zu akzeptieren" abgehakt, da dies bereits nach #44709 mit dem der Fall ist dotdoteq_in_patterns und inclusive_range_syntax Funktionen. Was bleibt, ist nur Dokumentation und Stabilisierung.

Antrag auf Stabilisierung

Ich möchte den inklusiven Bereich um 1,26 (Beta am 30. März, stabil am 11. Mai) oder früher stabilisieren. Ein Stabilisierungs-PR wurde als #47813 eingereicht.

Zusammenfassung

Die folgenden 3 Funktionen werden stabilisiert:

• inclusive_range_syntax — Die Syntax von a..=b und ..=b in einem Ausdruck:

  for i in 1..=10 {
      println!("{:?}", &a[..=i]);
  }
  

• dotdoteq_in_patterns — Die a..=b Syntax in einem Muster:

  match c {
      b'0'..=b'9' => c - b'0',
      b'a'..=b'z' => c - b'a' + 10,
      b'A'..=b'Z' => c - b'A' + 10,
      _ => unreachable!(),
  }
  

  (Hinweis: Die Syntax a...b wird weiterhin ohne Warnungen akzeptiert)

• inclusive_range — Die std::ops::{RangeInclusive, RangeInclusiveTo} Typen und ihre Felder:

  let r = 1..=10;
  assert_eq!(r.start, 1);
  assert_eq!(r.end, 10);
  

Dokumentation

Mehrere Dokumentations-PRs werden von @alercah eingereicht, danke!

• Das Buch: https://github.com/rust-lang/book/pull/1134
• Die Referenz: https://github.com/rust-lang-nursery/reference/pull/215
• Rust-by-Example: https://github.com/rust-lang/rust-by-example/pull/1015

Tests

Testfälle finden Sie in:

• run-pass/range_inclusive.rs —
  grundlegende Tests wie die Verwendung von a..=b in einer for-Schleife, als Iterator, als Slice-Index und Vorrang des ..= Operators und Typprüfungsverhalten.
• libcore/tests/iter.rs —
  weitere Tests zum Verhalten von a..=b als Iterator; überprüft, ob die Spezialisierungen von nth() , min() , max() und last() korrekt funktionieren und dass nach dem Aufruf von (5..=5).next() der Bereich zu 1..=0 .
• liballoc/tests/str.rs , liballoc/tests/btree/map.rs und liballoc/tests/vec.rs —
  überprüft, ob a..=b in verschiedenen Sammlungstypen korrekt funktioniert.
• parse-fail/range_inclusive.rs und ui/impossible_range.rs —
  stellt sicher, dass unsinnige Konstrukte wie a..= und ..= als Ausdruck nicht kompiliert werden können
• parse-fail/range_inclusive_dotdotdot.rs —
  stellt sicher, dass wir die veraltete Ausdruckssyntax a...b und ...b ablehnen.
• run-pass/inc-range-pat.rs —
  stellt sicher, dass die Verwendung von a..=b und a...b in einem Muster akzeptiert und gleichwertig ist.
• compile-fail/range_traits-1.rs und compile-fail/range_traits-6.rs —
  stellt sicher, dass RangeInclusive und RangeInclusiveTo PartialOrd nicht implementieren (wie die anderen Bereiche) und RangeInclusive Copy nicht implementieren (kann nicht implementieren Sie Copy, da es sich um Iteratoren handelt).
• libcore/tests/ops.rs —
  überprüft, ob das Iterieren einer manuell erstellten RangeInclusive Instanz funktioniert.

Ungelöste Fragen

• Die Verwendung von a..=b in einer for-Schleife hat eine viel geringere Leistung als a..(b+1) da next() komplexer und weniger optimiererfreundlich ist. Dies wird derzeit in #45222 verfolgt. Dies wird derzeit durch #48012 gemildert, wenn Iteratormethoden anstelle einer for-Schleife verwendet werden.

  Möglicherweise müssen wir die Felder von RangeInclusive instabil halten, wenn wir uns noch nicht auf das Design in rust-lang/rfcs#1980 festlegen möchten.

Möglicherweise müssen wir die Felder von RangeInclusive instabil halten, wenn wir uns noch nicht auf das Design in rust-lang/rfcs#1980 festlegen möchten.

+1
Müssen Bereichsfelder direkt verfügbar gemacht werden, anstatt über eine methodenbasierte Schnittstelle?

@rfcbot fcp zusammenführen

Gemäß der Zusammenfassung von @kennytm schlage ich vor, dass wir die Syntax für den inklusiven Bereich ( ..= ) stabilisieren .

(Dennoch finde ich die geringere Leistung von ..= bedenklich, und ich frage mich, ob es Sinn macht, ..= vorerst nicht direkt in Iterator zu implementieren, in um dies abzumildern.)

Teammitglied @nikomatsakis hat vorgeschlagen, dies zusammenzuführen. Der nächste Schritt ist die Überprüfung durch den Rest der markierten Teams:

• [x] @BurntSushi
• [x] @Kimundi
• [ ] @KodrAus
• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [ ] @ohneboote

Derzeit keine Bedenken aufgeführt.

Sobald eine Mehrheit der Gutachter zustimmt (und keine Einwände erheben), tritt die letzte Kommentarfrist ein. Wenn Sie ein wichtiges Problem entdecken, das zu keinem Zeitpunkt in diesem Prozess angesprochen wurde, melden Sie sich bitte!

In diesem Dokument finden Sie Informationen darüber, welche Befehle mir markierte Teammitglieder geben können.

Ich frage mich, ob es sinnvoll ist, ..= vorerst nicht direkt implementierten Iterator zu machen, um dies abzumildern.

Diese stabilen Eigenschaften werden für RangeInclusive<T> für mindestens einige T s im aktuellen Nightly implementiert: Iterator , FusedIterator , ExactSizeIterator , Debug , Clone , Eq , PartialEq , Hash , TrustedLen .

@SimonSapin Ich habe vergessen, haben wir die Struktur bereits stabilisiert? (Mit anderen Worten, ist das beobachtbar?) Ich ging davon aus, dass dies nicht der Fall ist.

Abgesehen davon denke ich auch 1..2 und 1..=2 an den gleichen Stellen verwendet werden sollten, was dagegen spricht, hier Änderungen vorzunehmen, und stattdessen vorschlägt, dass wir nur Abhilfe schaffen und verbessern sollten Optimierungen.

Warum nicht Sonderfallbereiche, in denen end == MAX ? Das könnte dazu führen, dass die meisten inklusiven Bereiche denselben Code haben wie exklusive Bereiche, mit der Ausnahme, dass diejenigen, die direkt zur Grenze gehen, mehr Code haben. Da der end != Max Zweig end niemals ändern würde, könnte er leicht vom Optimierer inline eingefügt werden.

@nikomatsakis Nein, die Strukturen sind im Moment instabil. Der Vorschlag von @kennytm beinhaltet jedoch, sie zu stabilisieren.

@SimonSapin

Nein, die Strukturen sind im Moment instabil. Der Vorschlag von @kennytm beinhaltet jedoch, sie zu stabilisieren.

Ich verstehe; Tatsächlich habe ich deshalb erwähnt, dass wir die Iterator Impl jetzt oder nie entfernen müssten. =)

@SimonSapin Ich glaube nicht, dass wir die Syntax des a..=b Ausdrucks stabilisieren könnten, ohne die Struktur zu stabilisieren. Wir könnten jedoch die Felder instabil lassen, wenn wir glauben, dass wir es ändern können.

Richtig, ich wollte nicht sagen, dass wir die Typen nicht stabilisieren sollten, wenn die Syntax zum Konstruieren von Werten dieser Typen stabilisiert wird.

Huzzah für die Flucht aus dem Fahrradschuppen-Syntax und das Stabilisieren! :tada:

Angesichts einer Zeitmaschine würde ich argumentieren, dass keiner der Range-Typen :Iterator , sondern nur :IntoIterator . Aber so wie es jetzt ist, denke ich, dass die Konsistenz mit Range die beste Option ist. Wir können diesen Fall mit Chain in den Bucket "Nun, es stellt sich heraus, dass die interne Iteration manchmal

Eine andere Sache, die ungelöst war, auch im Zusammenhang mit der Iteration: Wollen wir uns nach der Iteration auf eine bestimmte Darstellung von RangeInclusive festlegen? Im Moment landet es bei 1..=0 , aber es wurden auch andere Optionen besprochen . Ich weiß nicht, ob die Dokumentation ausreichen würde, um die Leute davon abzuhalten, sich darauf zu verlassen, obwohl die aktuelle den Post-Iteration-Bereich ziemlich nutzlos macht, was sie zumindest entmutigt.

Wir können diesen Fall mit Chain in den Bucket "Nun, es stellt sich heraus, dass die interne Iteration manchmal nur schneller ist" einordnen.

Ich denke, wir müssen es wirklich reparieren, um nicht weniger Leistung als ein exklusives Sortiment zu haben; es gibt keinen grundlegenden grund dafür.

es gibt keinen _grundlegenden_ Grund dafür.

Es hängt davon ab, welche Invarianten wir durchsetzen können. In den beiden vorherigen Formulierungen mit einem zusätzlichen Zustandsbit gab es nichts, das erzwingt, dass dieses Bit tatsächlich gesetzt wurde, als wir mit der Iteration fertig waren (und tatsächlich wurde es _nicht_ auf Literale wie 100..=0 ), also die Schleife Die Exit-Bedingung muss zusammengesetzt sein, was bedeutet, dass LLVM nicht mehr bereit ist, sie für uns abzuwickeln, sodass wir eine schlechtere Leistung erzielen. Das scheint vollständig zu beheben, was bedeutet, entweder die Struktur größer zu machen und keine Pub-Felder zu haben, RangeInclusive: !Iterator oder LLVM bei der Optimierung dieser Art von Schleifen besser zu machen.

Das heißt, ich habe verschiedene Möglichkeiten ausprobiert, um RangeInclusive::next schreiben, und es sieht so aus, als ob die Entscheidung meines früheren Ichs, auf einem Option<Ordering> abzugleichen, LLVM sehr traurig macht – nur Vergleichsoperatoren dort zu setzen, gibt etwas viel bessere Montage. PR bearbeiten : https://github.com/rust-lang/rust/pull/48057

Angesichts einer Zeitmaschine würde ich dafür plädieren, dass keiner der Range-Typen :Iterator ist und sie nur :IntoIterator sind. Aber so wie es jetzt ist, denke ich, dass die Konsistenz mit Range die beste Option ist. Wir können diesen Fall mit Chain in den Bucket "Nun, es stellt sich heraus, dass die interne Iteration manchmal nur schneller ist" einordnen.

Dem stimme ich grundsätzlich zu.

:bell: Dies geht jetzt in seine letzte Kommentarperiode , wie in der obigen Überprüfung beschrieben . :Glocke:

:bell: Dies geht jetzt in seine letzte Kommentarperiode , wie in der obigen Überprüfung beschrieben . :Glocke:

@rfcbot fcp abbrechen

@Withoutboats und @KodrAus haben ihre Kästchen nicht

@cramertj- Vorschlag storniert.

@rfcbot fcp zusammenführen

https://internals.rust-lang.org/t/psa-tweaks-to-fcp-process/6775

Teammitglied @cramertj hat vorgeschlagen, dies zusammenzuführen. Der nächste Schritt ist die Überprüfung durch den Rest der markierten Teams:

• [x] @alexcrichton
• [x] @aturon
• [x] @cramertj
• [x] @dtolnay
• [x] @eddyb
• [x] @nikomatsakis
• [x] @nrc
• [x] @pnkfelix
• [x] @sfackler
• [ ] @ohneboote

Derzeit keine Bedenken aufgeführt.

Sobald eine Mehrheit der Gutachter zustimmt (und keine Einwände erheben), tritt die letzte Kommentarfrist ein. Wenn Sie ein wichtiges Problem entdecken, das zu keinem Zeitpunkt in diesem Prozess angesprochen wurde, melden Sie sich bitte!

In diesem Dokument finden Sie Informationen darüber, welche Befehle mir markierte Teammitglieder geben können.

:bell: Dies geht jetzt in seine letzte Kommentarperiode , wie in der obigen Überprüfung beschrieben . :Glocke:

@rfcbot fcp Bedenken Bereichsmuster haben ein Problem mit der Operatorpriorität - https://github.com/rust-lang/rust/issues/48501.

( @petrochenkov Die Syntax ist <strong i="6">@rfcbot</strong> concern KEYWORD , ohne fcp . Ich denke jedoch, dass nur das markierte Teammitglied ein Problem melden kann.)

Die letzte Kommentarfrist ist nun abgeschlossen.

Wenn #48501 ausreicht, um die Stabilisierung zu blockieren, müssen wir wohl warten, bis #48500 zusammenführt (und stabilisiert)? Ugh, ich hoffe, wir finden einen schnelleren Weg. Diese Funktion hat so lange auf sich warten lassen und befindet sich jetzt in einem prekären Zustand, in dem Fehlermeldungen auf instabile Syntax hinweisen.

@durka
Ich glaube nicht, dass diese Stabilisierung erfordert, auf die Stabilisierung zu warten https://github.com/rust-lang/rust/pull/48500.
... in Mustern existiert immer noch und es hat immer noch die alte Priorität. Wenn Sie also &BEGIN ... END in einem Muster haben (das sollte ziemlich selten sein, vermute ich), gibt es immer eine Option, es nicht in ..= zu ändern

Ich denke, wir können #48500 ziemlich schnell stabilisieren

Persönlich wäre ich in Ordnung, wenn ich es "insta-stable" lande

inclusive range wurde stabilisiert, da der Pull-Request #47813 zusammengeführt wurde, aber nicht in der Version 1.25 enthalten ist, warum? Obwohl der Pull-Request am 16. März zusammengeführt wurde

@mominul eine Funktion ist erst verfügbar, nachdem sie in den Master-Zweig zusammengeführt wurde, also ist ..= ab 1.26 verfügbar, nicht ab 1.25.

Auf diese Weise können Sie sie in der Beta und nachts testen, bevor sie in den stabilen Zustand verschoben werden.

Danke für die Inputs @kennytm und @clarcharr ! Rust 1.26 Release ist zumindest für mich definitiv nicht langweilig! :Lächeln:

Ich weiß, dass es zu spät ist, um in diese Diskussion einzusteigen, aber warum nicht die Syntax .. ganz weglassen und stattdessen Wörter verwenden?

In Scala gibt es 1 to 4 das [1, 2, 3, 4] generiert, 1 until 4 das [1, 2, 3] generiert, und ein optionales by Schlüsselwort, das folgt, das die Schrittgröße angibt : 1 to 10 by 2 = [1, 3, 5, 7, 9] .

Dies macht sowohl die Absicht deutlicher als auch vermeidet den "Off-by-One"-Fehler, über den jeder so besorgt zu sein scheint.

Zugegeben, dies bricht den gesamten vorhandenen Code, wenn die ursprüngliche Syntax nicht unterstützt wird.

@ElectricCoffee in to und until als Schlüsselwörter einführen, um das zu unterstützen, und das wäre eine viel größere Veränderung.

Es funktioniert gut in Scala, aber die Designentscheidungen von Rust unterscheiden sich stark.

@ElectricCoffee Obwohl ich das gerne hätte, glaube ich nicht, dass es erwünscht ist, die zusätzlichen Schlüsselwörter dafür hinzuzufügen.

Ich glaube, dass eingebaute Sprachschlüsselwörter auf ein Minimum reduziert werden sollten, da sie mit Funktions- oder Variablennamen kollidieren könnten.

Obwohl to und until keine Wörter sind, die in den std (soweit ich weiß), bin ich sicher, dass es sich um gängige Wörter handelt, die in anderen Kisten verwendet werden und Projekte.

@daboross das ist eigentlich ein fairer Punkt, den ich nicht bedacht habe, obwohl a .. b in gewisser Weise a to b , unabhängig davon, was a und b tatsächlich.

Und ja, @timvisee sind sie wahrscheinlich.

@ElectricCoffee Aber wenn to ..= und until .. bedeuten würde, a until b schreiben, nicht a to b statt a .. b . Wie Sie sehen können, ist es nicht „mehr“ intuitives diese Worte als Betreiber zu verwenden .. Aber es wäre ausführlicher zu schreiben until überall , dass .. verwendet wird, weil es viel häufiger ist als ..= (wenn also Wörter verwendet wurden, sollte .. das kürzere Wort zugewiesen werden).

Und Sie haben absolut Recht damit @Boscop , es war jedoch nur ein Beispiel dafür, wie Worte gemacht werden können.

Ich glaube, ich habe to für exklusive und upto für inklusive in einigen Sprachen auch gesehen.
Es war alles als Idee gedacht.

In Scala wird der inklusive Bereich häufiger verwendet als der exklusive und daher das kürzere Wort.

@timvisee Man kann einfach a.to(b) und a.until(b) , es werden keine zusätzlichen Schlüsselwörter benötigt (und die Syntax wird dadurch nicht viel ungeschickter).

@hyst329 Daran habe ich gar nicht gedacht. Ich muss sagen, die Idee gefällt mir sehr gut! Du hast in der Tat recht.

Ich glaube jedoch nicht, dass dies ein richtiger vollständiger Ersatz für die aktuelle (/neue) Syntax wäre. Aber es wäre eine schöne Ergänzung.

Ich muss Boscops Kommentar zur Intuitivität zustimmen. Abgesehen von Wörtern wie "inklusive" und "außer" unterscheidet das alltägliche Englisch nicht wirklich stark genug zwischen inklusiven und exklusiven Bereichen, um eine fertige Abkürzung zu geben.

Sofern es nicht in einem Kontext verwendet wird, in dem auch "A bis B" verwendet wird, ist es mehrdeutig, ob "A bis B" im alltäglichen Sprachgebrauch hier in Süd-Ontario, Kanada, einen inklusiven oder exklusiven Bereich bedeutet und "bis" damit verbunden ist mit der Zeit stark genug , dass, wenn sie in diesem loseren Sinne verwendet, ist es unklar, ob das „Ereignis“ , dass „bis“ zuordnet ist „ bis wir sehen X“ oder „bis wir X verarbeitet haben“.

@hyst329 Sie als Methoden zu haben, würde die Bereiche jedoch auf

Ich denke, wir könnten dem Auftakt zum Erstellen von Bereichen ein neues Catch-All-Merkmal hinzufügen, aber das grenzt immer noch an eine grundlegende Änderung für Dinge, die tatsächliche to und until Methoden haben.

Ich gestehe, ich dachte, der Vorschlag von Schlüsselwörtern sei ein Aprilscherz.
Die ..= Syntax wurde stabilisiert.

Am Do, 5. April 2018 um 13:53 Uhr schrieb David Ross [email protected] :

@hyst329 https://github.com/hyst329 Sie als Methoden zu haben, würde einschränken
reicht jedoch bis zu Zahlentypen. Ich hätte wirklich lieber keine Syntax für
Zahlenbereiche und ein anderer für Bereiche anderer Dinge.

Ich schätze, wir könnten dem Auftakt zum Erschaffen ein neues Catch-All-Merkmal hinzufügen
reicht, aber das grenzt immer noch an eine bahnbrechende Veränderung für Dinge, die
tatsächliche bis und bis-Methoden.

—
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/rust-lang/rust/issues/28237#issuecomment-379021814 ,
oder den Thread stumm schalten
https://github.com/notifications/unsubscribe-auth/AAC3nwBj-b985q1Ez0OHDEHkG6DWV_5nks5tlloZgaJpZM4F4LbW
.

Ja, wir haben mehr als 300 Kommentare zu diesem Thema erhalten, und der allererste Kommentar lautet:

In diesem Thread sollte keine Syntax-Diskussion mehr geführt werden . Alle anderen Vorschläge für eine exklusive Bereichssyntax sollten im Forum des Benutzers oder im internen Forum erfolgen, nachdem Sie alle vorhandenen Kommentare und deren Begründung hier gelesen haben. Bemerkenswert ist, dass das Aufbrechen der Abwärtskompatibilität kein Starter ist.

Ich werde dieses Thema vorerst sperren, tut mir leid, wenn ich auf die Zehen trete!

Ich glaube, dass alles, was von diesem Thema abgedeckt wird, erledigt ist. Bitte öffnen und aktualisieren Sie die Checkliste in der ursprünglichen Nachricht des Problems, wenn es etwas anderes gibt.