Mam problem ze zrozumieniem, dlaczego w trybie ścisłym występuje błąd składnidelete jest używany na niekwalifikowanym identyfikatorze.

W większości przypadków ma to sens ... jeśli deklarujesz zmienne w zwykły sposób za pomocąvar słowo kluczowe, a następnie próbuje użyćdelete na nich, w trybie nie-ścisłym, po cichu nie powiodło się, więc ma sens, aby tryb ścisły zawiódł z błędem w tych przypadkach.

Istnieją jednak przypadki, w którychżargon usuń identyfikatory, któresą wykwalifikowany:

(function() {

  // "use strict";

  var obj = Object.create({}, { bloop: { configurable: false } });

  delete obj.bloop; // throws TypeError in strict mode, silently fails in non-strict.

  console.log('bloop' in obj); // true

}());

Tryb ścisły musi wykonać tutaj kontrolę środowiska wykonawczego, ponieważ w razie napotkania błędu generowany jest błąd TypeError. Są też przypadki, w których tymogą pomyślnie usuń niekwalifikowane identyfikatory w trybie nieostrym ...

// "use strict";

window.bar = 6;

console.log(typeof bar); // number

delete bar; // works in non-strict, syntax error in strict!

console.log(typeof bar); // undefined

W rzeczywistości, jak rozumiem, to, czy można usuwać rzeczy (w trybie nie ścisłym) zależy od wewnętrznego[[Configurable]] nieruchomości i nie ma nic wspólnego z kwalifikowanymi identyfikatorami. O ile wiem, w trybie ścisłym nie ma sposobu na usuwanie zmiennych nieglobalnych, które (jako właściwości lokalnego VO)są konfigurowalny:

(function() {

  // "use strict";

  eval('var foo = 5;');

  console.log(typeof foo); // number

  delete foo; // works in non-strict, SyntaxError in strict.

  console.log(typeof foo); // undefined

}());

Więc moje pytanie brzmi: po co rzucać błąd SyntaxError podczas używaniadelete na niekwalifikowanym identyfikatorze, gdy błąd TypeError rzuci mimo to, jeśli właściwość nie jest konfigurowalna? Wydaje się to niepotrzebnym ograniczeniem, aw niektórych przypadkach wydaje się, że nie ma żadnego obejścia innego niż nie używanie trybu ścisłego (trzeci przykład). Czy ktoś może wyjaśnić motywację tej decyzji?

Aktualizacja: Właśnie zdałem sobie sprawę, że pomijam fakt, że jest bezpośrednieval wywołania mają swój własny zakres w trybie ścisłym, zamiast zakresu funkcji wywołującej, więc w trzecim przykładziefoo nie zostanie zdefiniowany w trybie ścisłym. W każdym razie, sprawdzanie środowiska wykonawczego nadal by to wykryło, ale rodzi się pytanie dodatkowe: czy nie ma możliwości posiadania zmiennych lokalnych w trybie ścisłym, tak jak w przypadkuevalCzy zmienne deklaracje są nieostre? AFAIK, który był jednym z niewielu legalnych zastosowańeval.