Godot: GDScriptのプライベート変数または関数

変数に最も近いのは、 setgetを使用して、何もしないか警告を出力する関数を作成することです。 しかし、いいえ、真のプライベート変数や関数はありません。

@YeldhamDev悲しいことに、 setgetは役に立ちますが、公共の財産を見たくない場合は、これを行う方法はありません。 それは悪いです、 @ reduzあなたはどう思いますか？

Pythonでも不可能です。先頭に2つのアンダースコアを付けても、変数へのアクセスと変更が妨げられることはありません。 Pythonでは、代わりに規則を使用します。変数がプライベートであることを示す1つの先頭の下線、定数であることを示すALL_CAPS ...どこからでもアクセスできますが、実際には問題ではありません。

@NathanLovatoたぶん、その場合、GDScriptはPythonとは異なるはずですか？

@Chaosusプライベート変数が必要な理由を説明する引数を提供する必要があります。 そうでなければ、誰かがこれに取り組むことはありそうにありません。

プライベート変数は、データをカプセル化し、他のクラスとの結合を防ぐためにここにあります-他のクラスがこれらの変数にアクセスするのを防ぎます。 そもそもそれらにアクセスしない場合、問題も解決されます。

どちらの場合も（privateキーワードを使用するか、規則を使用して記述する）、変数をプライベートにするタイミングと方法、変数にアクセスできるタイミングと方法を学習する必要があります。 後でインターフェースを壊すことなく内部を変更できるように、またその逆もできるように、クラスの設計を学ぶ必要があります。 コードアーキテクチャに関しては、これが最大の問題の原因だと思います。

Pythonに関しては、何百万ものPython開発者が利用できます。 変数を「プライベート」にするメカニズムがあり、直接アクセスを防ぎます。それは簡単です。1つではなく2つの先頭のアンダースコアを記述します。 しかし、私はまだ誰かがそれを使用しているのを見たことがありません。 最近までJSでも利用できませんでした。 おそらくそのような他の言語があります。

GDscriptに含めるべきではないと言っているのではありません。他の人がこの機能をうまく利用しているかどうかは本当に気にしません。 私はそれがそれほど有用であるとは確信していません。 たとえば、Godotは、オートコンプリートで先頭に_または2が付いた変数を一覧表示できませんでした（ただし、仮想関数の規則として_function_nameを使用します）。

GDScriptでインテリセンスを使用した内部メソッドを表示したくないので、C＃やその他の静的型付き言語のようにします。

ええ、私は実装が難しく、新しいキーワードが必要であることに同意します。非常に小さな結果には多大な労力が必要です。
プレフィックスが「__」のソリューションは、問題を部分的に解決します（おかげで）（私はPythonを使用したことがないので、これは私にとって新しいことです）。

私はこれがすでに閉じられてアーカイブされていることを知っています（これについて別の問題が開かれるべきかどうかはわかりません）が、アクセス修飾子はどのプログラミング言語でも非常に重要な機能です。 Godot用の新しいノードアドオンを作成したいときに、新しいノードにノードの外部で変更してはならない内部状態変数がある場合、それを妨げるものは何もありません。 この機能を模倣するために先頭の下線を使用できることを理解していますが、それでもアクセス修飾子全体であるアクセスを妨げることはありません。 私の意見では、他の人があなたのオブジェクトと相互作用する方法を制御する方法がないので、これはかなり大きな問題です。

ええ、私は@dylmeadowsに同意し

私は間違いなくプロのプライベート関数と変数でもあります。

1. はい、メソッド名の前に_を使用するプライベートの規則がありますが、仮想関数にもまったく同じ規則が使用されます。 したがって、アンダースコアが表示された場合は、「その機能に触れないでください」という意味である可能性があります。 または「その関数を上書きしてください！」。 正直なところ、それは危険です。

2. 私が一人で、または小さなプロジェクトで非常に小さなチームで作業している場合、どの関数が使用されることを意味し、どの関数が内部使用のみを目的としているのかがわかっているので、それほど重要ではありません。
   しかし、チームが成長するにつれて、これはますます困難になります。 人々はいつも自分で書いたわけではないクラスで働いています。私は物事を機能させるために小さな内部関数をたくさん書いているので、人々がこれらの関数を呼び出さないようにしたいと思っています。意図しない動作やバグにつながる可能性があり、ミスが発生するとこれらを修正するのに時間がかかります。 すべての後、彼らは外部から呼び出し可能であるため、共通の慣習にもかかわらず、これらのものは、より大きなチームで何が起こっされます。

3. 少なくとも最後のではなく; オートコンプリート。 私はクラスが何ができるかを学ぶためにこれをよく使う人です。
   私はそれを「。」 最後に、どの関数がポップアップするかを確認します。 何か役に立つと思えば、私はそれを使います。
   とにかく呼び出されるはずのないすべての関数が散らかっていなければ、はるかにクリーンになります。 それに加えて-そして何度も-私はまだこれらの_name関数がプライベートか仮想かを知りません。

また、プライベート変数は個人的なプロジェクトでも役立ちます。 自分が取り組んでいるゲームに取り組むことができない期間があるので、自分の機能のいくつかが何をしているのかを忘れ始めます。 または、どちらを使用すべきか、使用すべきでないかを忘れています。

プライベート変数はこれで素晴らしいでしょう！ 変数または関数にノードの外部からアクセスできないようにします。プロジェクトに戻ったときに、変数の使用方法を推測でき、すべてのコードをもう一度完全に読み取る必要はありません。

Byteronとdylmeadowsが言ったことも2番目です。 彼らはちょうど彼らの投稿を十分によく書いて、私が考えていたことを正確に言いました。 私の2セントを追加したかっただけです。

何人かのユーザーが興味を持っており、これについて話し合いたいので、再開します。 まだ計画されていませんが、コミュニティに強い関心があるかどうかについて話し合い、確認することができます。

Pythonは、理想として言及している最高の言語ではありません。
Godotは非常にオブジェクト指向であると言われています。 すべてのスクリプトもオブジェクトです。 オブジェクト指向プログラミングの主な原則の1つは、カプセル化を提供することです。 外から手を触れずに何かをしたいのなら、それはおそらく最良の理由です。

個人的には、人々が変数を編集したり関数にアクセスしたりするのを絶対に防ぐ_ （または_internal_など）を付けます。

変数/関数をオートコンプリートから隠すだけのキーワード（または同様のキーワード）には反対しません。 アクセスを完全に防ぐ必要はないと思います。

一方では、禁止するのではなく、警告する方が良いです。 しかし一方で、プライベートフィールドとメソッドは通常何度も使用されます。 また、長い変数名（ _internal_variable ）は少し面倒です。
いずれにせよ、キーワードprivateが存在しても、それを使用する必要はありません。

クラスのプライベートメンバーを定数のようなものにします。 同様に、変数名をBIG LETTERSに記述して、その値を変更しないことに同意することができます。 しかし、私たちはそれをしませんね？ つまり、プライベート変数は、通常の変数と定数のクロスです。 この場合、特別なキーワードを入力してみませんか？

はい、メソッド名の前に_を使用するプライベートの規則がありますが、仮想関数にもまったく同じ規則が使用されます。 したがって、アンダースコアが表示された場合は、「その機能に触れないでください」という意味である可能性があります。 または「その関数を上書きしてください！」。 正直なところ、それは危険です。

それが私がここで見ている最大の問題です。 privateキーワードの代わりに、 virtualキーワードを使用できるでしょうか。 一部の仮想メソッドは、「func」を記述するときにすでにオートコンプリートに表示されるため、上書きするはずの仮想関数とオートコンプリートに表示されるべきではないプライベート関数を明示的に区別するキーワードで十分な場合があります。 virtualキーワードの利点は、 privateよりも使用頻度が少ないため、書き込みが少なくなることです。

プライベートクラスのメンバーも含まれているのを見て嬉しいです。 これが他の言語に存在する理由があります。 他の消費者/チームメンバー（またはあなた自身）は、すべてのクラスがどのように機能するかを知る必要はありません。 実際、彼らはおそらく、とにかく内部にあるはずの機能をいじくり回すオプションさえ持ってはいけません。

先頭のアンダースコアは、これがプライベートメンバーであることを「示す」必要があることを理解していますが、実際には、それを変更することで仕事が完了するかどうかは誰も気にしません。 これは、プラグインとして使用したい場合に特に苦痛であり、誰もが好きなように変更できます。 作成するオブジェクト/スクリプトの状態を完全に制御したいと思います。 誰かが好きなときに状態のあらゆる側面を変更できるオブジェクトがあると、他の人がイライラする以上に消費できるコードが生成されます。

それに加えて、「利用可能な」変数/関数のリストを整理するのは素晴らしいことです。

開発チームに1つの推奨を行うことはできますか？それでは、これらすべてを考慮してください。 オートコンプリートリストの順序を変更します。 文字または数字で始まらないvarまたはfuncは、オートコンプリートリストの__Bottom__に表示されます。 次に、アイテムを表示するには、_を入力する必要があります。さらに、名前に他の非数学記号または論理記号を使用できると便利ですか？ まだ試していませんが、€Displayまたは¥Printは許容できる関数名ですか？ NS。

さらに、名前に他の非数学記号または論理記号を使用できればいいのではないでしょうか。 まだ試していませんが、€Displayまたは¥Printは許容できる関数名ですか？ NS。

https://github.com/godotengine/godot/issues/24785を参照して

したがって、これをいじくり回した後、何もしないセッターを定義すると、別のスクリプトで同じ変数に新しい値を割り当てて印刷しようとしても、元の値は次のようになるという結論に達しました。印刷されます。 プライベートではありませんが、十分近いと思います...

公開されているように見え、変更したばかりの変数が変更されていないというヒントがまったくないことを意味しますか？
このメソッドを広範囲に使用するコードのデバッグを楽しんでください。

空のセッターの代わりに、エラーを出力することもできます。

プログラムを起動して実際にそのコード行に到達すると、実行してはいけないことを実行したことしかわかりません。 コードを書いている間はまだ公開されているように見え、単一のプライベート変数を設定するには複数行のコードが必要です。
置くprivateその変数の前には道短く、コードの追加の回線を必要とせず

GDScriptは動的言語であるにもかかわらず、私にはかなりC ++っぽい感じがします。 C ++でのコードの記述からGDScriptに切り替えると、これらのアクセス修飾子が失われます。 そうは言っても、GDScriptは確かにOOPの完全なサポートを欠いています。

私はこの問題をざっと見ただけですが、名前の前にアンダースコアが付いている場合は、少なくとも関数と変数をオートコンプリートから非表示にできると便利です。 それに関する顕著な問題は、それが仮想関数であるかどうかを判断することであり、したがって、おそらく関係なく表示されるはずです。

アンダースコアは仮想関数にも使用されており、仮想関数も公開したい場合があります。

アンダースコアが前に付いた関数を他のノード/オブジェクトからのみ非表示にするかもしれませんが、自己/ベースでの呼び出しに対してはそれらを表示します。

私の提案は、仮想関数には単一のアンダースコアを使用し、「プライベート」関数には二重の先行アンダースコアを使用することです。 このようにして、仮想関数に影響を与えることなく、オートコンプリートからそれらを隠すことができます。

変数のアクセス_attribute_を変更するときは、その_name_を変更する必要があるため、アンダースコアを使用して変数を非表示にするのは適切ではありません。 実際、 variableと_variableは異なる名前です。
これもUNIXファイル名のドットのようなものです。かなり物議を醸す決定です。

これが私の意見です

• プライベート関数のプレフィックス「__」
• 「__」が付いている関数はオートコンプリートに表示されません
• 「privatefuncx（）」は、「func __x（）」のシンタックスシュガーです。

上記は、「__」で始まる変数を含むコードを壊します。 でもそれを除けば、理想的なシステムだと思います。

これまでのGDScriptの機能はPython / JSと非常によく似ており、これらの言語はどちらも非常に正当な理由でプライベート変数と関数を持っていません。これは、設計哲学とは完全に正反対です。 あなたには自由があり、その自由は重要です。それがコーディングを容易にするものです。 あなたはカプセル化を犠牲にします、しかしそれは彼らの哲学です。 真のカプセル化は、タイプチェックなしですでに壊れています[すべてのタイプを自分でチェックしない限り、そうすることはないでしょう]。 したがって、厳密な型指定を実装しない限り、プライベート変数は間違っていると感じます。 OOPの勾配では、厳密な型付けはプライベート変数の前に来ます。 厳密な型付けはあるがプライベート変数がない言語はたくさんありますが、プライベート変数があり厳密な型付けがない言語は知りません。 これもまた、正当な理由があります。 さらに、JSを使用すると、継承ツリー全体にアクセスでき、それらの側面も変更できます。 オブジェクトを持つ任意のコードによって、実行時にオブジェクトが継承するクラスを変更できます。 もちろん、それは起こりませんが、デザイン哲学を示しています。

したがって、私の意見では、真のプライベート変数は言語を大幅に妨げるでしょう。 とにかく、Pythonのシステムはそれをうまくやっていると思います。プライベート変数にアクセスするために使用できる__がありますが、内部的なものをいじっていることは明らかですが、それでも意味のある制限はありません。 真のOOP設計哲学を望む人は、単に「__」を使用したり、会社やプロジェクトのコーディングスタイルで使用したりすることはできません。 たぶん、それをエラーとしてマークするオプションがいいでしょう。 つまり、一般的に、ダックタイピングとプライベート変数は実際には一緒になりません。 少なくとも、名前空間を完全に台無しにするのは、「hi」がプライベートの場合、obj.set（ "hi"、5）が機能しないためです。 しかし、「こんにちは」が存在しない場合は機能しますか？ それはあまり意味がありません...だから、あなたが何をしてもプライベートに完全にアクセスできないようにすることは非常に強いことではありません、それが私の投票です。 Pythonが現在行っているように、プライベート変数が存在することは非常に強力です。 Tbh本当にアクセスできないプライベート変数が必要だったとしても、プライベート変数を使用したダックタイピングの問題を解決する方法がまだわかりません。 obj.setをブロックして、エラーをスローさせるだけだと思います。 ここで、obj.setはブール値を返す必要がありますが、これは奇妙なことです。 is_private呼び出し？ obj.setを使用する前に呼び出す必要がありますか？ idk

[ああ、本当のところ、実際のエラー検出を取得できますか。プライベート変数について話していますが、現時点では、gdscriptにバグがある場合、ゲームはそれを黙って無視します（facepalm）。 たぶん私はそれを間違っていますが、私のコードが何かを行うと、違法なgdscriptが関数からnullを返すように見え、追跡が非常に難しくなります。JSはこれまでになくひどく、JSは言語の混乱です。 ゲームのクラッシュが多すぎる可能性があることはわかっていますが、コードがどこで壊れたかを把握するために、前者が印刷され、後者が印刷されない2つの連続するprintステートメントが見つかるまで、printステートメントを配置してコードベースをバイナリ検索する必要があります。 JS / Pythonは、他のすべてにおいてどれほど自由であるにもかかわらず、その意味で驚くほどはるかに厳格です。]

問題を最小限に抑えるために、一貫性のあるプロジェクト組織を見つけることをお勧めします。 シーンのルートノードをインターフェイスとして使用して、外部からシーンを制御し、子スクリプトをバックエンドとして使用できます。

または、メソッドのみを使用し、変数とシグナルをエクスポートし、外部から単純な変数に触れないようにすることもできます。 これは単純な規則であり、GDScriptはその単純さを維持できます。

Pythonでも不可能です。先頭に2つのアンダースコアを付けても、変数へのアクセスと変更が妨げられることはありません。 Pythonでは、代わりに規則を使用します。変数がプライベートであることを示す1つの先頭の下線、定数であることを示すALL_CAPS ...どこからでもアクセスできますが、実際には問題ではありません。

私が言いたいのは、Pythonで_private_属性を持つことが可能であるということです。

引用（https://www.python.org/dev/peps/pep-0008/）：

__double_leading_underscore：クラス属性に名前を付けるときに、名前マングリングを呼び出します（クラスFooBar内では、__ booは_FooBar__booになります。以下を参照してください）。

__double_leading_and_trailing_underscore__：ユーザーが制御する名前空間に存在する「魔法の」オブジェクトまたは属性。 例：__ init __、__ import__、または__file__。 そのような名前を発明しないでください。 文書化されているとおりにのみ使用してください

そのリンクをクリックしてCTRL + Fで「プライベート」にすると、次のように表示されます。

Pythonでは実際にプライベートな属性はないため、ここでは「プライベート」という用語を使用しません（通常は不要な量の作業が必要です）。

二重アンダースコアまたは単一アンダースコア変数は、通常の変数と同じように機能します。これらは使用しないでください。ライブラリを更新すると内部変数であるため、変更される可能性があることを参照するための慣例です。 一般に、GDScriptのようなPython言語はオブジェクトを単なる辞書であるかのように扱うため、プライベート変数を強制して名前空間を消費させるのは厄介です。

そのリンクをクリックしてCTRL + Fで「プライベート」にすると、次のように表示されます。

Pythonでは実際にプライベートな属性はないため、ここでは「プライベート」という用語を使用しません（通常は不要な量の作業が必要です）。

二重アンダースコアまたは単一アンダースコア変数は、通常の変数と同じように機能します。これらは使用しないでください。ライブラリを更新すると内部変数であるため、変更される可能性があることを参照するための慣例です。 一般に、GDScriptのようなPython言語はオブジェクトを単なる辞書であるかのように扱うため、プライベート変数を強制して名前空間を消費させるのは厄介です。

私は同意します、彼らはそれを_private_属性とは呼びません。 ただし、その仕組みについて説明します。

# defining class Employee
class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.__salary = salary

>>> emp = Employee("Bill", 10000)
>>> emp.__salary
# AttributeError: 'employee' object has no attribute '__salary'

したがって、_private_属性とは呼ばれませんが、ほとんど同じように動作します。
Pythonに存在するので、GDScriptにほぼプライベートな属性があると便利です。

そうそう、私はあなたに強く同意します。 Pythonは、._ Employee__salaryを使用するためのシンタックスシュガーを提供しているだけです。 私は個人的にPythonのやり方が好きではなく、コメントで述べたように、Godotで大幅に改善できると思います。

class Employee:
      var name # normal
      private var salary # Syntactic sugar for var _salary

_Employee__salaryは変数名を隠すための醜い方法であり、プライベートキーワードを使用すると、通常のOOPと同じようになるため、これはよりクリーンです。 さらに良いことに、これはパブリック変数salaryとプライベート変数_salaryを持つ機能をブロックします。これは醜く、Javaの場合と同じように構文エラーになることが望ましいです。 これは、両方が「varsalary」と「privatevarsalary」と宣言されるためです。これは明らかな矛盾です。 別の考え方として、「メンバーmを持つ他のクラスCのプライベート変数にアクセスするには、C._mのようにアンダースコアを使用する必要があります」というものがあります。 次に、アンダースコアで始まる変数の宣言をエラーにする可能性があります。つまり、変数を宣言する唯一の方法をプライベートにして、何が行われているのかが明確になるようにします。

Pythonの状況が望ましいとは言えない唯一の理由は、変数の上部に宣言がなく、関数本体のいずれかでクラス変数を構成しているためだと思います。 GDScriptはクラス本体で宣言を必要としているようで、Javaのようなプライベート宣言を簡単に理解できます。

多くの入力を節約しない限り、シンタックスシュガーとして機能するキーワードを使用するのは好きではありません。 ここで、 privateと入力すると、実際にはより多くの文字を書き込むことができるため、ショートカットになります：slightly_smiling_face：

また、メソッドはどうですか？ いくつかの仮想メソッドはアンダースコアで始まるため、単一のアンダースコアを使用してそれらをプライベートとしてマークすることはできません。 ただし、2つのアンダースコアを使用することもできます。これにより、長くなるという犠牲を払って競合を回避できます。 また、理にかなっている場合はPythonの規則に従うというアイデアも気に入っています。「ダンダー」は、その言語でしばらくの間人気がありました。

ショートカットとして表示することを意図しているとは思いません。代わりに、クラスの外部で「_」を使用してプライベート変数にアクセスするという考え方です。 シンタックスシュガーは、その実装方法になります。 Pythonのやり方と本質的に同じです。 しかし、そうです、それは本当です。Pythonの場合、構文シュガーは多くの入力を節約しますが、それはそれが愚かな長いものにエイリアスするからです。 短いものにエイリアシングする方が厳密に優れているため、エイリアスを短くして、エイリアスが短すぎるためにその構文の糖衣構文を使用しないことを選択すると、プライベート変数をサポートする必要があるかどうかになります。 必ずしもそうする必要はありません。ユーザーに変数の前にアンダースコアを付けるか、独自の規則を選択するだけです。 これは、JavaとC ++に関心のある人々のためのものであり、「_ myvariable」を慣例としてプライベートとして使用するのではなく、「private var myvariable」と記述します。これは、OOPの世界から来たときに、両方が正確に達成したとしても、奇妙に感じます。同じこと。 二重アンダースコアはPythonの構文と非常によく一致するので、特に_が他のものと競合する場合は、私もその構文に賛成です。

むしろ、スタイルの規則としてのみ誤解される可能性のあるもの以外の動作を明示的に定義するキーワードが必要です。 privateが私の票を獲得します。

議論に火をつける：「プライベート」メンバーのPythonスタイリング規則は、名前の前にアンダースコアを追加することです。これは、 _ready() 、 _inputなどの一般的なイベントメソッドで別の目的でgdscriptによって_すでに_使用されています。いくつか_input 、および_physics_processです。 それらはプライベートになっていますか？ プライベートキーワードを追加すると、これらのメソッドとどのように相互作用しますか？ protectedような他のキーワードも実装する必要がありますか？

いずれにせよ、私はすべて、ユーザーに規則を定義させるのではなく、_設計によって_制限的なディレクティブを適用することに専念しています。 しかし、実装の複雑さを考えると、プライベートクラスのメンバーが意図した改善を提供するかどうかはわかりません。 API全体も再検討する必要があると思います。 言語全体は完全に異なるパラダイムを持っているでしょう。

ええ、誰かがすでにそれを指摘しました。 （Calinouの応答を参照してください）二重下線が進むべき道です。 Pythonと同じです。

私の2c。 Pythonでは、 _で始まるクラスメンバーへのアクセスを妨げるものはなく、 __に関する内部知識も必要です。

それはすべて意図を示すことです。 哲学は、私たち全員が大人であり、おそらくプライベートな変数または関数に本当にアクセスする必要があるかどうかを判断できるということです。 そして、そうする場合、私たちは自分たちで結果に対処する必要があります。

@sanchopanca

1. GDScriptはPythonではありません。
2. ロジックに従って、定数も必要ありません（var CONSTANT = 1）。
3. 誰もが__を使うのが好きというわけではありません。

私はprivateキーワードを使用していますが、互換性を損なうことはありません。
代わりに、 _を使用してfuncとvar非公開にすると、他の理由でそれを使用すると、いくつかの点で状況が変わります（ _は関数のパラメーターでのみ使用します） ）。

これは、新しい静的型付け機能を思い出させます。このプライベート機能と仮想機能は同じように機能します。
それはより明確なコードベースを提供し、より良いエラー検出、より良いオートコンプリート、そしてコードの自動文書化も提供します。
誰かがあなたのコードを読んだら、彼らはそれが何をするのかをよりよく理解するでしょう。

開発チームにとって、2つの新しいキーワードを実装するのはどれほど難しいのだろうかと思います。
確かにタイピングシステムよりもはるかに簡単で、多くの価値を提供します。
開発チームの誰かが私に何をすべきかについての指針を与えることができれば、私は正直になるのを手伝って喜んでいます！

プライベートキーワードと保護されたキーワードを追加するための投票をもう1つ追加するだけです。
他の開発者が使用するコードを書いたことがあれば、それに反対することはできません。
キーワードを追加することに対してすべてがこのトピックをチェックすることができます：
https://softwareengineering.stackexchange.com/questions/143736/why-do-we-need-private-variables

引き続きGDscriptを使用しますが、その過程でGDscriptを改善してみませんか。

_、__、___などは、タイプを提案するために変数名にプレフィックスを追加するのと同じくらい愚かです。
intAge、strName、bIsAlive ...これらはすべて、欠落している言語機能のみを示しています。
したがって、GDScriptをPythonや他の言語と比較しなくても、開発者はポーリングを実行して、これら2つのキーワードが必要かどうかを確認できます;）

この機能が実装されている場合は、C ++の方法が選択されることを願っています。 すべての宣言の前にある「private」または「public」キーワードは、C＃を読みにくくします。

私は個人的にC ++の方法を好みません。なぜなら、C ++の入力構文がなく、デフォルトですべてが公開されるからです。 私は、privateキーワードがあまり表示されない以上に、別の行を追加したり、新しい行に移動したりせずに変数をprivateに設定できる値を持っています。

private var foo : String = "foobar"は、既存のexportおよびonreadyキーワードの使用法とも一致しています。

機能の提案がGodotの提案リポジトリで追跡されるようになったため、 https：//github.com/godotengine/godot-proposals/issues/641を優先して終了します。