Rust: 可変ローカル専用のvarキーワード

告白する必要があります。最初は、可変変数と可変フィールドに同じキーワードを使用する必要があると思いましたが、 varはちょっとよく読みます（ let mutは嫌いではありませんが）

可変変数の宣言は、不変変数よりも少し面倒な機能だと思います。 プログラマーが「var」だけを使用して「一貫性がある」か、「var」の方が強力であることがわかります（後で変更する場合は変更する必要はありません）。 そうすると、全体的にコードが読みにくくなります。

Rustが深刻な束縛と規律の言語であるべきだと示唆しているわけではありませんが、正しい方向への穏やかな微調整は道徳的に正当であると私は思います（つまり、ルールは「安全なコードの場合、より安全な構造はより強力なものよりもノイズが少ないはずですが混乱しやすい構造」）。

一方で、私はこれが好きです。なぜなら、それはこのフォームから視覚的な曖昧さを取り除くからです：

let mut x = 4,
    y = 8;  // is y mutable or not?

しかし、私はシルバンを支持する傾向があります。 可変を宣言することは必ずしも_醜い_である必要はありませんが、1回のキーストロークだけで、不変よりも作成するのが非常に便利でない場合は理にかなっていると思います。 activatingキーワードも独特である必要があり、（IMO） varは、デフォルトで不変性を誇る言語で可変性を具体的に伝えるには、汎用変数宣言キーワードとしてあまりにも広く使用されています。 そして、 varが私たちのletである貧しいC＃プログラマーについて考えてみてください！

上記のコードスニペットに対処するために、 let mutを単一のキーワードに置き換えるというアイデアは今でも気に入っていますが、 mut自体で十分な場合

@pcwaltonは、 mutを使用するだけの問題を指摘しました。レコードリテラルとブロック式にはあいまいさがあり、解決するには任意の先読みが必要です。

{ mut x: int ...

リテラルを記録しますか、それともローカル変数でブロックしますか？

多くのプログラマーが、 varがRustで変数を宣言する方法であり、 letをまったく使用していないことを知っているのを見ることができました。 結局のところ、 varは、JavaScriptなどの言語でローカル変数を宣言する方法です。 これはこの提案の良いところだと思う傾向があります。

昨日誰かがletとvar長さが同じになると指摘しているのを耳にしました。これは、位置合わせに適しています。

私はやや無関心ですが、短いのでvar方が好きです。 私が見ているように、可変性を煩わしくすることは望ましい目標ではありません。 （確かに、プログラミング言語の役割は、何か迷惑なことをすることではなく、同じことではない_clear_だけだと思う​​傾向があります。）

letとvar一緒に使用することにはまだ警戒していますが（Javascriptと同じですが、100％異なります）、変数を検出するためのlintパスがあれば問題ははるかに少なくなります。変更可能として宣言されていますが、実際には変更されていません。

可変性をタイプの一部にする計画があります。 それは地元の人々に影響を及ぼし、これを無関係にしますか？

どうですか：

val x = ... // immutable (val-ue)
var y = ... // mutable (var-iable)

Scalaのように。

@brsonは正しいと思います。この問題は、 mutをタイプに移動すると消えます。つまり、 let x = mut 10;を取得します。

今のところこの問題を閉じます。 あなたが私が間違っていると思うなら、再開してください！

これについてはよくわかりません。 mutをタイプに移動するというアイデアは好きですが、それが「完了した取引」であるかどうかはわかりません---そこには長引く奇妙さが存在する可能性があります。 いずれにせよ、私はlet x = mut 5と書くかもしれないとは思っていませんでした。今日と同じように、 let mut x = 5と書くといつも思っていました。 変数の型の「可変性」は、変数に割り当てられている値ではなく、宣言された方法に由来します。

行うには、そうでない場合は、あなたが配列している場合ことを意味すると思われるxのタイプの[mut int]し、あなたが書いlet y = x[0] 、次にy変更可能なのですか？ か何か？ それは望ましくないようです。

@Dretch val / varは明確ではないので好きではありませんが、Scalaの前例は素晴らしいです。

デフォルトでvar使い方を学ぶ人々についての@eholkの懸念を共有します。 現在の動作方法では、すべてを不変として宣言する傾向があります。コンパイラは、変更可能である必要があることを通知し、 mutます。 これは間違いなく良い振る舞いであり、 var/let分割ではあまり気になりません。 varとletも同様に困難ですが、 let mut入力することもできません。 let let mutを入力せずにlet 。

しかし、私には好みはありません。3文字のキーワードで始まるステートメントだけで関数を作成できるとありがたいです。

@nikomatsakis特に、単一割り当てに関するルールは、タイプではなく宣言の

私は@pcwaltonに同意するvar不必要に使用している人々に関する懸念については、 varバインディングが単独で割り当てられている場合に文句を言うオプションの警告を追加できます。 しかし、rustcと標準ライブラリで良いスタイルの先例を作ることもできると思います。

デイブ

プログラマーがすべての変数を可変であると宣言した場合、それは本当にひどいことですか？ varが変数の宣言方法であると考えるRustプログラマーのセットと、ほとんどの場合letを使用することを理解している別のセットがある場合、それは世界の終わりではないようです。必要に応じてvar 。 最初のRustプログラマーとして、 letとvar正しく使用することを支持する先例を設定できます。

IMHOの優れた構文設計とは、やりたいことすべてを便利にするだけでなく、言語のセマンティクスと設計目標の「スムーズなパス」に人々を優しく誘導することです。

たとえば、Rust（a la Haskell）のリンクリストに特別な構文サポートを追加することはおそらくないでしょう。Rustの基本原則の1つは効率的であり、リンクリストの普及はその原則に反して機能するからです。 同じ理由で、スレッド間で可変デー​​タを共有することはおそらくあまり便利ではありません（安全な並行性は別の原則であるため）。また、任意のintをポインターにキャストすることは非常に便利ではありません（メモリの安全性が大きな原則であるため）。

これらのことを行うことが不可能であることは言うまでもありませんが、Rustを書く慣用的な方法である構文から明らかなように、比例して不便です。

可変（ローカル）変数はこれらのどれよりも悪くはありませんが、Rustが正確性と保守上の理由（私が個人的に同意するもの）のために不変データを実際に支持している場合、構文は理想的にはその方向に穏やかに微調整する必要があります。 単一の追加の文字や追加の修飾子の印章、または「let」が「letmut」や「let！」よりも複雑でないことを明確にするのに十分なものでさえ。 または何でも、したがって、変数を変更可能にする必要が実際にない場合は、デフォルトとして使用することをお勧めします。

@ssylvanああ、私はその点を理解しています。それは程度の問題であり、トレードオフのバランスです。 私たちはすでにデータ構造の不変性を促進しており、IMO不変ローカルは不変フィールドよりも促進することが重要ではありません。 （特に、IINM以降、可変ローカルがヒープクロージャでエスケープすることは許可されていません。）また、列数を変更せずにletとvar間でリファクタリングする機能が失われることは、不変の地元の人々を促進する。 数値化するのが難しいので、それは私の気持ちだと思います。

デイブ

その場合、「let mut foo = bar」ではなく、少なくとも「let foo = mutbar」または「letfoo：= bar」で最初のトークンが整列します。 おそらく変数名は可変長になるので、ステートメントの残りの部分で余分な修飾子を避けることはそれほど重要ではありません。

ああ、私は:=アイデアに少し偏っています。

デイブ

考え直してみると、パスカルは永久にクールではありません。 私はそれを取り戻します。 :)

デイブ

また、 let foo := bar 、次のようなことを防ぎます。

let mut foo;
foo = bar;

同じパターンを書く別の方法が常にあるように思われますが、私はそのパターンが時々役立つことに気づきました。

@eholkそれがそれを妨げるとは思わない。 しかし、ほとんどすべての主流言語のプログラマーにとっては、それでも奇妙に見えると思います。

デイブ

:=に関して

let foo = "hello";
let foo := "hell";

現在の構文に対するbrsonの議論（つまり、可変宣言は最初に不変宣言を必要とする）は説得力があります。 プログラミング言語がぎくしゃくしない限り、プログラミング言語が意見を述べられれば、それは完全に素晴らしいことです。 :)

=と:=は興味がありません。 val 、 varおよびそれらのバリエーションとはほとんど反対です。 それが可変性を制御することは単に_明白_ではありません。 つまり、どちらかを採用しても嫌悪感を持ってやめることはありませんが、「ニーモニックを説明する必要がある」というのは悪い兆候だと思います。 私はもっ​​と大丈夫です：

• タイプに指示させる。
• mutだけをローカル宣言子として機能させ、パーサーにレコード構文とローカル宣言のコミットを1つの追加トークンで遅らせるように要求します。 それでもLL（1）は、追加の中間文法状態を追加するだけで、追加のバックトラックはありません（どちらの方法でも有効です）。
• let mutままにしておきます。

「偶発的な」変更可能なローカルを回避する主な理由は、環境キャプチャを導入したため、それらが遠隔作用の形式になり、借用などのさまざまな分析の危険性が生じるためです。

（すべてのletは最初は変更可能でしたが、環境キャプチャもバインドのみでした。現在、バインドはなく、envキャプチャのみです。Tomayto、tomahto。）

現在、可変変数を暗黙的にキャプチャすることはできないと思います。

@graydonは、2つの元々の動機があったことは正しいです。 ただし、関連するのは1つだけです。 2つの動機は

• fn@内の可変変数の暗黙的な「コピーによる」キャプチャ
• どのデータが変更可能で何がborck用ではないかを理解する

後者はもはや関係がないことが判明しました。 可変/不変変数の使用は実際にはあまりにも粗雑だったので、borrowckは変数を「一時的に」借用するという考えを持っています---ポインターが入っている間に変数が変更されない限り、可変変数は不変ptrで借用できます範囲。

おそらく、可変/不変のローカルの概念を削除して、古いルールに戻ることができます---すべてが可変です。 その後、クロージャの作成後にクロージャに暗黙的にコピーされた変数が変更されたときに警告を発行できます。

3番目の動機があります：不変の変数は推論するのが簡単です。 すべてが可変である場合は、関数全体をスキャンして、変数がその存続期間中にどのような値を持つ可能性があるかを確認する必要があります。 すべての変数には潜在的に複雑なデータフロー（特にループ、ブランチ、可変関数パラメーターなど）があり、すべてのステートメントを注意深く分析しないと何が起こっているのかを確認するのは困難です。 関数内に1つまたは2つの可変変数しかない場合は、それらに「フラグを立てる」ように機能するため、裾を含むコードを読むときはより注意が必要です。

@Dretch 「val」と「var」のキーワードを使ったScalaスタイルも好きです。

現在の構文によって、ミュータブルが親指のように突き出るのが好きです。 コードのスキャンが簡単になります。 valとvarは、その点で視覚的にあまりにも似ているようです。 ミュータブルが絶対に目立つ必要があると言っているわけではありませんが、キーワードを視覚的に区別することは、使いやすさの重要な側面です。

可変フィールドが錆から取り除かれることを理解しています。 これは、レコード/ブロック内の変数のあいまいさがなくなるため、 let mut代わりにmut使用できることを意味しますか？

また、構造的な記録が進んでいると思います。これにより、可変フィールドが残っていてもあいまいさがなくなります。

@Dretch変更可能なフィールドが出て行く途中であり、構造レコードがすでになくなっているのは事実です。

私はこの問題にほとんど無関心ですが、凍結/解凍の場合、 mutがそれ自体で宣言キーワードであることが理にかなっている可能性があることを指摘したいと思います（Dretchが提案しているように） 。 今日比較してください：

let foo = 1;  // immutable
/* 10,000 lines of code here */
let mut foo = foo;  // we're making foo mutable, totally understandable
/* 10,000 lines of code here */
let foo = foo;  // potential wtf

提案とともに：

let foo = 1;  // immutable
/* 10,000 lines of code here */
mut foo = foo;  // a mutable foo, no problems here
/* 10,000 lines of code here */
let foo = foo;  // slightly less of a potential for wtf, since we officially have two declaration forms

また、これによりRust-ismの「mutがないことは不変性を意味する」の一貫性が低下するように感じますが、 foo = 1;だけでなくlet foo = 1;記述しているためです（後者の形式は明らかに宣言には望ましくありません）。

Kotlinはvalとvarも使用します。

この変更を行うつもりはないと思いますが、明確に定義されたマイルストーン1にノミネートするので、それを解決することができます。

mutをパターンバインディングに移動することと互換性がないため、コンセンサスはこれを行わないことです。 閉鎖。