JavaScript為什麼不實現捨去引數的用法?

時間 2021-06-02 02:14:54

1樓:navegador

折衷的土辦法:

const e$ = undefined在鍵盤上比 _ 更靠近左手//鍵盤上$ 附近的字母只有e 和 r//epsilon ε形狀和 e 相近function tst(a=400, b=20, c)> tst(e$,e$,555)

400 20 555

> tst(123,e$,555)

123 20 555

但是這個命名與習慣的流命名有衝突還有個方法是改小鍵盤對映,比如我的鍵盤很容易敲出下面幾個字元 ε, ,,λ, 這樣就可以方便的定義一些東西

> const ε = undefinedundefined

> const = undefined

undefined

> tst(ε,ε,555)

400 20 555

>

2樓:賀師俊

有這樣的提案 devsnek/proposal-unused-function-parameters ,但是沒有能進入 stage 1。會議紀要在此:tc39/notes。

簡單說,TC39裡某些代表對任何新語法都很敏感,像允許未使用引數這樣看上去效用並不是很大的提案就幾乎不可能通過。

我也參與了該次會議(會議紀要裡JHX是我)。我個人對該提案是中立的,至少不反對其進入stage 1的,實際上我最後還希望允許其進入stage 1以便Babel能提供官方支援,讓社群可以試用和提供反饋。不過我確實也認為該提案效用不高,而且幾個可能的語法都有一些問題,即使能進入stage 1怕也很難繼續推進。

從具體語法方案來說,我其實反對捨去引數(即題主的「理想的語法狀態」)。陣列空槽(形如[1,,2])本身就是乙個不好的設計(難以判斷到底是不小心輸入錯誤還是真的想要空槽),不應擴大這種不好的設計。

我個人略支援下劃線方案,即放寬重名規則,允許多個引數都使用下劃線(這樣不需要像題主的示例裡寫成gt; ...,而可以寫成(_, _) => ...)。

不過總體上說,gt; ...也並沒有糟糕很多。更嚴格的基於約定(未使用的變數必須以下劃線開頭,使用到的變數不能以下劃線開頭)、配合linter的方案在工程上也是完全可行的,故而也未必需要進入核心語言。

BTW,如果早兩年就有該提案且進入stage 1的話,可能try ... catch {}(省略catch引數)提案就不會被通過(其動機可以用try ... catch(_) {}解決),至少不會那麼快進入JS語言中。

實話說,optional catch我認為是乙個沒啥用處的特性。

當前JS中「捕捉自己關心的錯誤,rethrow不能處理的錯誤」這種正確做法寫起來非常麻煩,在任何乙個呼叫層級上太容易出現吞掉所有錯誤(包括TypeError、ReferenceError等本質上意味著程式編碼bug的不可恢復錯誤)的不良pattern。

optional catch一定程度上進一步鼓勵了此種不良pattern。

PS. 我設計的雙端解構和迭代提案(tc39/proposal-deiter,目前stage 1)的擴充套件中包含了略有類似的特性,理論上允許你寫a((..., c) => {})。

不過注意其語義和(_, c) => {} 是不一樣的,並不是跳過乙個引數,而是只使用最後乙個引數,忽略前面的引數。因此其應用場合是不同的,只有明確使用最後乙個引數(比如node.js中以callback為最後乙個引數的慣例)才可以用。

濫用的話可能會產生問題(比如API公升級新增乙個引數的情況)。以上。

3樓:d41d8c

({}, c) => 這種語法大概符合要求。

不過我個人覺得,即使不用,也可以用下劃線+名字來表示這個沒用到的引數「應該」有什麼意義。

為什麼JavaScript裡面typeof null 的值是 object ?

自由的囚徒 這是JS語言本身的乙個bug。不同的物件在底層都表示為二進位制,在js中二進位制前三位都為0的話會被判斷為object型別,null的二進位制表示全是0,自然前三位也是0,所以執行typeof時返回 object 阿布丁 說句人話,不說書裡的鬼話 因為 所有引用型別的名字是乙個指標,指的...

你為什麼選擇 JavaScript ?

牆外一枝花 多年前,面試的時候,一邊是三年.net 給你6k,一邊是3個月js也是6k,所以沒那麼多為什麼,最初的選擇源於人性的最基本訴求,溫飽。 題葉 最開始上網,沒人教程式設計,我唯一能折騰的東西只有瀏覽器,高中用 GreenBrowser 替換了 IE 自以為很開心,後來知道 Opera,最後...

JavaScript 為什麼要把 this 暴露出來

孫竟 這是動態語言帶來的靈活性啊,Python 也是這樣。在不需要靈活性的地方,你完全可以不用 this。可是你用到了,就說明你確實需要。舉例來說,你怎麼在 C 裡傳遞乙個物件的方法?想想都覺得很麻煩。而 JS 可以把乙個函式和物件通過 Function.prototype.bind 繫結在一起 即...