Request for Comments: Strikte unäre Operatoren

Veröffentlicht am 15. Juni 2022 von Natalie Weizenbaum

Wissen Sie, was margin: $a -$b in Sass bewirkt? Wenn Sie mit „genau dasselbe wie margin: $a (-$b)“ geantwortet haben, tut es mir leid, aber Sie liegen falsch. Es ist *eigentlich* dasselbe wie margin: $a - $b. Keine Sorge, Sie sind nicht die erste Person, die von dieser seltsamen Ecke des Sass-Parsers gestolpert ist! Aber unser neuer Sprachvorschlag zielt darauf ab, das zu beheben.

Im Vorschlag Strict Unary Operators, der derzeit für Community-Feedback offen ist, schlagen wir vor, Ausdrücke der Form $a -$b zunächst zu verwerfen und dann schließlich nicht mehr zuzulassen. Wir wissen, dass Verwerfungen nie angenehm sind, aber sie sollten relativ schmerzlos sein, wenn sie kommen: Sie können einfach $a - $b oder $a (-$b) schreiben, je nachdem, was Sie beabsichtigen. Wir werden auch ein Sass-Migrationswerkzeug zur automatischen Aktualisierung Ihrer Stylesheets bereitstellen.

Veraltet

  • $a -$b wird nicht mehr zulässig sein, da unklar ist, was der Autor beabsichtigt hat, und das aktuelle Verhalten wahrscheinlich falsch ist.

Immer noch zulässig

  • $a - $b wird weiterhin funktionieren, da es eindeutig die Subtraktion anzeigen soll soll.

  • $a (-$b) wird weiterhin funktionieren, da die Klammern das unäre Minus eindeutig machen.

Die Optionen $a - $b oder $a (-$b) werden von allen weit verbreiteten Sass-Versionen unterstützt, sodass es für Bibliotheken keine Probleme geben sollte, diese Verwarnung zu vermeiden und ältere Sass-Versionen weiterhin zu unterstützen. Zusätzlich können Sie immer das --quiet-deps Befehlszeilenflag oder die quietDeps JS API Option verwenden, um Warnungen von Abhängigkeiten stummzuschalten, die Sie nicht kontrollieren.

Warum funktioniert es so?Warum funktioniert es so?  Permalink

Warum, fragen Sie sich vielleicht, wird $a -$b überhaupt so geparst? Die kurze Antwort ist: "weil andere Programmiersprachen es so machen". In den meisten Programmiersprachen werden Operatoren unabhängig vom vorhandenen oder fehlenden Leerzeichen genauso geparst. Wenn Sie $a - $b als Subtraktion parsen, sollten Sie $a -$b auch als Subtraktion parsen.

Das Problem für Sass ist, dass wir auch die Verwendung von durch Leerzeichen getrennten Wertelisten von CSS übernehmen, sodass Benutzer in einigen Kontexten erwarten, zwei Ausdrücke nebeneinander schreiben zu können und diese so geparst zu bekommen, wie sie es würden, wenn sie jeweils einzeln verwendet würden. Diese beiden Prinzipien geraten in Konflikt und führen zu der Verwirrung, die dieser Vorschlag beheben soll soll.

Warum nicht einfach die Funktionsweise ändern?Warum nicht einfach die Funktionsweise ändern?  Permalink

Theoretisch könnten wir Sass ändern, sodass $a -$b genauso geparst wird wie $a (-$b): eine durch Leerzeichen getrennte Liste von zwei Werten, wobei der letztere ein unäres Minus hat. Wir haben uns aus zwei Gründen dagegen entschieden:

  1. Pragmatisch gesehen ist es schmerzhafter, eine Breaking Change vorzunehmen, die das Verhalten bestehender Syntax ändert, als eine, die die Syntax nur vollständig verbietet. Es erfordert mehr Releases und mehr verschiedene Sass-Versionen mit unterschiedlichem Verhalten. Außerdem öffnet es die Tür für ein Stylesheet, das viele Versionen auf einmal aktualisiert, um auf das neue Verhalten umzuschalten, *ohne einen Fehler zu erzeugen*, was zum schlimmstmöglichen Szenario führen könnte: die Bereitstellung falscher Styles.

  2. Es ist nicht offensichtlich, dass $a -$b in jedem Fall als $a (-$b) geparst werden *sollte*. Benutzer, die von anderen Programmiersprachen kommen, erwarten möglicherweise, dass es genauso geparst wird wie in diesen Sprachen. Selbst in Sass wird $a -$b innerhalb von calc() weiterhin eine gültige binäre Operation sein. Es ist vielleicht kein eleganter Stil, aber manchmal steht die Formatierung nicht an erster Stelle im Gedanken des Autors!

Lassen Sie uns wissen, was Sie denken!Lassen Sie uns wissen, was Sie denken! Permalink

Wenn Sie Gedanken oder Meinungen zu dieser Änderung haben, lesen Sie bitte den vollständigen Vorschlag und reichen Sie dann ein Issue mit Ihrem Feedback ein. Wir lassen dies einen Monat lang offen für Kommentare, danach werden wir den Vorschlag finalisieren und mit der Implementierung beginnen.