Rust: デフォルトの引数とキーワード引数

まだ誰も反対を表明していませんが、それについての計画はありませんでした。 私は長い間この問題について考えてきました、そしてそれは基本的にデフォルトの引数の要求に要約されます。 私はそれが次のように見えると思います：

fn foo(bar: int, qux=2: int, ham=0: uint) { ... }

これは、 foo(1) 、 foo(1, 3) 、 foo(1, ham=4) 、 foo(6, 7, 8)などと呼ぶことができます。

編集：以下のhuonwの提案された構文を参照してください。これは、現在の宣言構文ではるかに良く、より均一に見えます。

トリアージ2013-08-05 :(私が知っている）進歩はありませんが、それでもきちんとしています。 多分宣言構文は次のようになります

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

ここで、RHSは任意の定数expr（つまり、 static宣言で有効なもの）です。

IMOこれらは本当に便利です。不特定の引数を追跡するためにデフォルトにフォールバックすることしかできない_defaultarguments_のC ++システムでさえ素晴らしいでしょう...オーバーロードほど複雑ではないが、代替の名前付き関数バリアントの数を減らします。構造体と列挙型のバリアントでもそれらを宣言できるのは素晴らしいことです。
おそらく、必要な動作のこの単純なサブセットは、名前付きキーワードパラメータを呼び出す方法/場合についてコンセンサスが得られる前に実装できます...内部の準備が整いますか？

式として実装することは実行可能/有用でしょうか...以前に指定された引数とジェネリック型パラメーター（たとえば、ゼロを検索する機能::、またはslice（＆self、 start：uint 、 end：uint = self.len （））/ * "foobarbaz" .slice（6）== "baz" ..またはcreate_window（parent、x、y、 width ：uint = parent.width （）/ 4、 height：uint = （width_161）/ 100）/ _デフォルトは黄金比のウィンドウで、サイズをまったく指定しない場合は画面幅が1/4になります。 ..またはそれはコード膨張のレシピのように聞こえますか..

C ++スタイルのデフォルトでは、haskellのような部分的なfunctoinアプリケーションが除外されますが、それがうまくいかない可能性があると聞きましたか？

デフォルトの引数の別のアイデアがあります。 引数を完全に削除するのではなく、デフォルトが存在する引数を_で呼び出すことができます。

したがって、 @ huonwの素敵な例を

fn foo(bar: int, qux: int = 4, ham: Option<int> = None) { ... }

...これをfoo(1, 2, None) 、 foo(1, _, Some(1)) 、 foo(1, _, _)などとして呼び出すことができます。

ただし、このアイデアはまだ厳密に位置付けられているため、キーワード引数を採用しても実際には何のメリットもありません。

タイトルを「デフォルトの引数とキーワードの引数」に変更します。

実装されていませんが、ast＆parserに追加してみました。 https://github.com/dobkeratops/rust/compare/default_args 、これはそれについて行く正しい方法ですか？ （オプション@expr .. exprが何であるかについての制約が必要になりますか？）
この機能を試すために、つま先を水に浸します。
翻訳できるC ++ APIのサブセットを増やすためにこれに熱心であり、それらは間違いなくC ++から見逃しているものであり、名前付きキーワード機能はC ++よりも優れています。
2番目に提案された宣言構文を使用するのは単純で論理的であるように思われました

見栄えのする@dobkeratops （ただし、 type Default = Option<@expr>はおそらく不要です）。

exprの制約はrustc::middle::check_constます; 各引数をチェックするcheck_fnような関数を追加する必要があります。 （また、おそらくデフォルトの引数が最後にのみ表示されるようにチェックする必要があります。タイプチェッカーrustc::middle::typeckとtransも何かが必要になると思います。 ）。

わかりました。フィールドには、不要な注釈が付けられるように名前が付けられています。
どこを見ればよいかを教えてくれてありがとう、私はrustc :: middle :: typeck :: .. mod.rs（check_fn something）を探していました。

「継続的インテグレーション」の名の下に、些細な基礎を広報として提出する価値はありますか。コードベースをよく知っている誰かが、他の部分を別のときにもっと速くできるかもしれません。
私は常に変化の発散について妄想的です

あなたがそれらに対して確実に決定した場合、それは唯一の破壊的ですか？

誰かがこの種のものは-Zオプションで入ることができると提案しました（..Session :: debug_opts ...しかし私はこれらのswereが現在どこにでも伝播しているのを見つけませんでした（例えばパーサーで）。

コンパイラがまだ使用していないものを解析することに反対するかもしれないことがわかります。おそらく警告からエラーに変更することができます...

@dobkeratops公式の開発者はまだこれについてコメントしていないので、PRが受け入れられる可能性は非常に低いことに注意してください。 ここでは、1）デフォルトの引数が必要かどうか、2）必要な場合は構文はどうあるべきか、3）キーワードの引数が必要かどうか（デフォルトの引数に選択したセマンティクスによってこれが妨げられる可能性があるため）について多くの議論があります。 ）。

さて、彼らは何もブロックしないので、まだ長い間非常に低い優先度になると思います（彼らは確かに私自身のウィッシュリストのトップではありません）。
ぶら下がっている果物かもしれないと思っただけで、C ++の人々にとってもう1つの親しみやすさ..
マクロは時々同様の仕事（およびそれ以上）を行うことができると思います。そして私は一般的/一般的でないバリエーションのためのより良い命名習慣に入ることができます

名前付き引数は重要ではないことがわかりますが、IMOのオプションの引数は重要です。 一部の場所では、特定の引数が不要な場合に簡単なインターフェイスを提供するために、同様の署名と同様の名前を持つメソッドをいくつか見たと思います。 機能が欠落しているという理由だけで、そのようなレガシー関数になってしまうと、それはひどいことになるでしょう。

ここには微妙な部分がたくさんあります。 デフォルトの引数はすべて暗黙的な形式のオーバーロードであるため、（推測では）特性解決アルゴリズムや型推論と統合される可能性があります。 それほど難しいことではないかもしれませんが、慎重に設計する価値があります。現時点では、そのための時間予算があるかどうかはわかりません。 _言語_機能として、下位互換性があると思います。 api機能として、それはおそらくapi設計にいくつかの情報を与えるので、bcリスクを表します。

@Seldaekデフォルトの引数が必要な場合は、stdlibの下位互換性を確保する前にそれらを実装することが重要であることに同意します。 ただし、少なくとも1つの言語（Go）を知っています。この言語は、デフォルトの引数を哲学的に拒否し、名前と署名がわずかに異なる関数のアプローチを採用しています。

ただし、Rustとは異なり、Goには、デフォルトの引数がないことによる苦痛を軽減するいくつかの機能があります。 一つには、それらは可変個引数機能を持っています。[1] 次に、構造体を作成するときにフィールドを省略できます。つまり、構成構造体を関数に渡すのは簡単です（省略されたフィールドは、ユーザーができるものではなく、コンパイラー指定（？）のデフォルト値に設定されているように見えます）。カスタマイズ）。[2]

前者の場合、同じ結果を達成するためにマクロハッカーを回避できる可能性があります（ただし、面倒な実装コストがかかります）。 確かに、 fmt!()の次の交換はこれを行います：

ifmt!("{foo} {1} {bar} {0}", 0, 1, foo=2, bar=3)

これは今日機能するコードです。

後者に関しては、私たちが持っている最良のアナログは、次のように機能的な構造体の更新を使用することです。

struct Foo { x: int, y: int, z: int }

impl Foo {
    fn default() -> Foo {
        Foo{x: 0, y: 0, z: 0}
    }
}

fn bar(f: Foo) {
    printf!(f);
}

fn main() {
    bar(Foo{y: 5, ..Foo::default()});
}

私は過去にこのメソッドがデフォルトの引数の欠如の回避策として手に負えないように提案されているのを見てきましたが、実際にはかなり不当です（ bar(Foo{y: 5, ..Foo::default()})とbar(y=5) 、または私のより保守的なbar(_, 5, _)提案を比較してください）

繰り返しになりますが、PythonとJavascriptの出身者として、私は明らかにデフォルトの引数を歓迎します。 ただし、APIを明示的にするというGoの哲学には多少共感します（API自体の関数の数を（潜在的に大幅に）増やすことと引き換えに）。

[1] https://groups.google.com/d/msg/golang-nuts/NWMReL1HueQ/X9mdYduCOB8J

[2] http://stackoverflow.com/questions/2032149/optional-parameters

また、クロージャーと相互作用し、関数へのファーストクラスの参照を取得することも指摘しておく必要があります。

@bstrieGoの概要をありがとう。 オーバーロードは紛らわしいAPIを作成するため、おそらく悪い考えであるという点に同意します。 同様に、必要なほとんどすべての引数でコールバックを受け取ることができるjQueryの「オーバーロードされた」メソッドは、非常に奇妙で、実装するのが面倒です。

また、デフォルトの引数を入力するラッパー関数がそれほど悪くない場合もあることに同意します。 しかし、問題は、いくつかの紛らわしいケースからあなたを救う一方で、他のケースでは多くの定型文を導入することです。 一例は*::to_str_radix(num, radix)です。 オプションの引数がある場合、これは*::to_str(num, radix = 10)で折りたたむことができます。 場合によっては、関数のバリエーションが爆発的に増えると、直感的で覚えにくくなることがあると思います。 明らかに私の2セントです。

それらを延期するのは良い時間のトレードオフであることがわかります。
しかし、哲学的にデフォルトを_本当に_省略しているのでしょうか、それとも、実装の時間と予算のトレードオフを正当化するだけなのですか？ long_function_names_with_lots_of_trailing_qualifiersをくぐり抜けることが一歩前進だと誰かが思ったら驚かれることでしょう:)しかし、彼らが「シンプルなツールを活用できるのなら、まだ強力なIDEを開発していません。」というのは別の問題です。

私は間違いなくC ++のオーバーロードとデフォルトの両方を見逃しています..しかし、Rustsの他の便利さとC ++の代替の約束（長い間1つの主要言語に固執した後..）と交換して満足しています。

実験のために、私はそれらを「パーサーハック」として実行しようと考えました...マクロのレベルで動作しますか？ 引数が欠落している呼び出しサイトでデフォルトのexprをインライン化しますか？
私はそれが受け入れられる設計である可能性は低いことを理解していますが、錆の機能で動作するデフォルトの引数を持つことは_不可能_ではないと私は信じています。

私がまだ本当に慣れていることの1つは、メソッドは理論的にはさびではるかに使いやすいということです。
C ++に戻ると、ヘッダー/依存関係の問題のためにそれらを恐れています（これが私がここにいる主な理由です）ので、私はしばしば本能的に最初に関数に行きます。
おそらく、rustを上手く使っていると、デフォルトを見逃すことが少なくなります。

アイデアが消えないように、 bar(Foo{y: 5, ..Foo::default()})のおしゃべりな側面は..Foo::default()部分のように思えます。

構造体構造体でフィールドを除外しやすくし、デフォルトに落とすことができれば、このアプローチの方が適しているかもしれません。

たとえば、次のような適切な特性（ ZeroまたはDefaultなど）を実装する構造に対してのみ定義された新しいフォーム：

Foo{y: 5, *)ここで、 *は以前の..Foo::default()の代わりになります。

次に、例は「ちょうど」 bar(Foo{y: 5, *})です。 たぶん他の人はFooもそこにないことを好むでしょうが、これは私にはかなりきれいに思えます。

列挙型は、C ++プログラマーが慣れているものとは異なるオプションのパラメーターのグループを便利に渡す他の方法や、呼び出しで注釈と値を散在させる方法も提供すると思います。
これは、セットアップパラメータがたくさんあるものを作成するような場合に適しているようです。

@pnkfelixこの例のFoo構造体は、おそらくはるかにわかりやすい名前になり、提案された砂糖を使用しても、実際には次のようになります。

html::start_server(html::ServerOpts{port: 10088, *});

少し見栄えがします。 新しい構文を保証するのに十分役立つのか、それともデフォルト引数のすべてのユースケースを満たすのに十分なのかはまだわかりません。

実際、私自身の例を使用すると、HTMLサーバーなどの多くのオプションを使用して何かを初期化するときに、事前にserver_opts構造体を設定してから、 start_server(server_opts)呼び出すのと同じくらい幸せです。 ..html::ServerOpts::default行を追加してもかまいません。

おそらく、デフォルトの引数が最も役立つ場所を再考する必要があると思います。 私にとって、それは潜在的な議論がたくさんある場所ではありません。 これらはかなりまれなはずであり、構成構造体を初期化するための数行で問題ありません。 むしろ、1）操作がかなり一般的であり、2）操作に多くても1つまたは2つの引数があり、ほとんどの場合不要ですが完全性のために必要な場合、デフォルトの引数をほとんど見逃します。 例えば：

let foo = Some('a');
foo.unwrap();  // same as today
foo.unwrap('z');  // imagine that this replaced unwrap_or_default

int::from_str("4");  // same as today
int::from_str("4", 16);  // imagine that this replaced from_str_radix

ただし、これらを入力したので、実際には個別のメソッドの明示性を好みます。 :)たぶん、私は結局何が欲しいのか本当にわかりません！

@ dobkeratops 、C ++の経験から、デフォルトの引数で有効になっている優れたC ++ APIの例をいくつか教えてください。

https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-08-13のコメントは、開発者がこれを遠い将来の機能と見なしていることを示しているようです。 指名。

OCamlはオーバーロードせずにオプション/デフォルトの引数を実行すると私は信じています。 デフォルト値のないタイプTのオプションの引数は、暗黙的にTオプションに変換され、関数は値が提供されたかどうかをチェックする必要があります。 引数が省略されたことをコンパイラに知らせるためのオプションの引数の宣言と使用にも制限があります。 すべてのオプションの引数にはラベルが必要です（オプションになるには、キーワード引数である必要があります）。 これはOCamlの型システムを複雑にします（ラベルは関数の型の一部になります）が、これは他のHindley-Milner型システムと相互運用しなければならないというアーティファクトだと思います。

C ++から来ているので、デフォルトの引数値を本当に見逃してしまいます。 私は多くの場合、多数のパラメーターを持つ関数を使用します。まれな使用法やテストケースを除いて、ほとんどの場合、それらのほとんどはデフォルト値を持っています。 デフォルト値の代わりに純粋に組み合わせ関数名の導関数を追加すると、非常に長い名前の大きな混乱が発生します。

デフォルトの引数やキーワード引数が非常に役立つことに同意します。 オーバーロードの観点から何をする必要があるかを概説し、おそらく構文について議論する必要がある、1.0より前の提案に向けて取り組むべきだと思います。

より多くの人が賛成してコメントしているのを見るのは良いことです:)私が欲しかったもう1つの理由は、シームレスに翻訳できるC ++ APIの量を増やすことでした。 C ++ライブラリを使用することは、C ++で立ち往生している大きな理由の1つです。

コミュニティがコア開発者にコストをかけずに_実装_できれば、これを実現する唯一の方法だと思います。
私は、彼らがもっと重要なことをしていることに同意します。列挙型は失われた多型を回復し、C ++で調整された脳にはすぐにはわからない可能性があります。

これが、ASTデータ構造に解析するための基礎を提出したかった理由です。 他の誰かがそれを手に取って解決策を見つけようとする準備ができているでしょう。 最初のフィードバックは私がPRをすることを思いとどまらせました。

C ++から私はscalaとpythonがこれに何を持っているかを羨望の的に見ています。 その優雅さを備えたネイティブの非GC言語は素晴らしいでしょう。
.. 1つの場所でより多くの機能を使用し、何が起こっているのかを把握するためのナビゲーションが少なくなり、ネストの深さが少なくなり、ソースコードのノイズが少なくなります。 タイピングが簡単に減るだけではありません。
多分あなたはそのより自己文書化を主張することさえできます、関数署名はそれがどのように使われたかについてあなたにもっと教えてくれます。

難しいのはタイプチェッカーであり、パーサーハックとして実行されただけの場合、微妙なバグの可能性と混乱を招くエラーを防ぎます。

このようなことを書くことができるかどうか想像してみてください。

fn substr(a:&str, start:int, end:int=a.len())->~str

エラーチェックなしでその種のものをASTにハックするだけで、多くのことがうまくいかない可能性があると確信しています..しかし、期待どおりにそれを修正できるかどうか想像してみてください:)

ただのバグ。 メリットについては議論できますが、リリースを妨げることはありません。

@tautologicoが彼のコメントで説明している振る舞いが好きです。

Rustに適用すると、これは次のように変換されると思います。

fn ga(bu: int, zo: Option<int>, meu: Option<int>) {
  let zo = zo.get_or_default(42);
  let meu = meu.get_or_default(99);
  ...
}

そして、これらはすべて有効な呼び出しになります：

ga(10, 20, 30); // 20 and 30 are automagically
                // converted to Some(20) and Some(30)
ga(10, 20);         // ga(10, 20, 99) 
ga(10);             // ga(10, 42, 99)
ga(10, None, None); // ga(10, 42, 99)
ga(10, 20, None);   // ga(10, 20, 99)
ga(10, None, 30);   // ga(10, 42, 30)

規則は、末尾のOption<T>パラメーターは省略できるということです。 ここでは、 Optionタイプが再利用されますが、これにより問題が発生した場合は、別のより具体的なOptParamタイプを作成できます。

この提案により、発信者は、その位置に関係なく、提供したいパラメーターとデフォルトのままにしておきたいパラメーターを正確に選択できます。 また、パラメータリストにデフォルト値が表示されないのも良いことだと思います。 このように、デフォルト値は定数式に限定されず、オブジェクトの状態に依存するか、他のパラメーターに依存する可能性があります。

GUIダイアログボックスを表示する関数の実際の例：

fn showDialog(message: ~str,
              parent: Option<Widget>,
              title: Option<~str>,
              type: Option<DialogType>,
              icon: Option<Icon>) { ... }

// Display an info box in the middle of the screen.
// Set the title to "information", translated in the current locale
// Set the icon to an "info" icon
showDialog(~"hello, world!");

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a "warning" icon
showDialog(~"sick, sad world!", None, None, WarningDialog);

// Display a warning box in the middle of the screen.
// Set the title to "warning", translated in the current locale
// Set the icon to a custom icon
showDialog(~"sick, sad world!", None, None, WarningDialog, bugIcon);

この例では：

• parentのデフォルト値はNone （親なし）です
• typeのデフォルト値はInfoDialog
• デフォルト値のiconは、 type値によって異なります。
• デフォルト値のtitleは、 typeの値と現在のロケールによって異なります。

現在、新しいプリミティブ型としてOptionを追加することも提案しています。 昔ながらのenumなので、今は完全にライブラリ機能です。

IMOのデフォルトの引数はキーワード引数の方が10億倍優れていることを付け加えたいと思います。 デフォルトの引数のアイデアは好きではありませんが、キーワードの引数は好きではありません。

一方はもう一方への足がかりであり、デフォルトはそれ自体でまだ有用です。いくつかの追加のフラグがあります。デフォルトが必要な場合は、それらを省略できます。
あなたが両方を持っているならば、それらはうまく結合することに同意しました。
こだわりのポイントは実際にそれらを実装しています:)
それをタイプチェッカー/タイプ推論器に後付けする方法..またはそれをスロットに入れる他の方法。

位置引数のデフォルト値は、不可解なコードになります。 キーワード引数のデフォルトだけではないのはなぜですか？ （これらが実装されている場合）。

IMO ...その「どちらか-または」ではありません。
どちらも便利です。 1つは実装が簡単で、構文の選択肢が少なくなります。
ですから、それを実行すること、または最初にそれを踏み台として実装しようとすることは理にかなっています...

デフォルトの値を省略すると、通常の関数呼び出しよりも不可解になりますか？ C ++プログラマーは、すでにthsiのパラメーターをソートすることに慣れています。 通常、ある種の制御フラグの単語は、最後に適切なデフォルトがあります。重要な情報のみをリストすることで明確にするために、（..、BLAH_DEFAULT）を書き込む代わりに、値を省略します。 Rustを必要とする人々は、すでにC ++を扱っている可能性が高いため、それに慣れています。

私は今日、上記の提案（構造体はキーワード引数の要素をすでに提供していると見なしているため、既存のstruct-extension構文を利用してデフォルトの引数に近いものを提供しようとした）が、提案していた構文という1つの重要な問題を無視していることに気付きました。 _every_引数のデフォルトを提供できると仮定しました（そして、それらはすべて単一の構造体パラメーターに持ち上げられます）。

もちろん、これは一般的には当てはまりません。1つには必須の引数があり、他の引数にはオプションがあることがよくあります。

関数宣言の構文をさらにいじくり回すのではなく、すでに持っている機能を活用する方法を見つけたいと思います。これは主に、関数/クロージャ/メソッドを書き留めるさまざまな方法のおかげで、関数宣言が_すでに毛深い_ためです。

私の現在のブレインストーミングは、おそらく構造体アイテムの定義にフィールドのデフォルト式を追加することによって、既存の構造体構文を活用できるかどうかに焦点を当てています。 これにより、削除できるフィールドと必要なフィールドを設定できるようになります。 何かのようなもの：

struct Foo { x: int = 0, y:int = 0, z:int = 0 }

fn bar(f: Foo) {
    printf!(f);
}

struct Baz { x: int, y: int, z:int = 0 }

fn quux(g: Baz} {
    printf!(g);
}

fn main() {
    bar(Foo{y: 5});
    quux(Baz{y: 5}); // ~ERROR: required field, `x`
}

@pnkfelix私はその提案が好きです。同じ内部構造体を活用するのはそれほど難しいことではないかもしれませんが、匿名の構造体を生成するでしょう。 したがって、例をとると、これは事実上、構造体を推測するためのコンパイラの魔法を少し加えた同じコードになります。

fn bar({ x: int = 0, y:int = 0, z:int = 0 }) {
    printf!(f);
}

fn quux({ x: int, y: int, z:int = 0 }) {
    printf!(g);
}

fn main() {
    bar({ y: 5 });
    quux({ y: 5 }); // ~ERROR: required field, `x`
}

@visionmedia @bstrie構造体名を削除することについて本当に心配する必要がありますか？ 再バインド使用宣言は、呼び出しサイトでの追加文字の最小数を3（名前+左右の括弧の場合）に

つまり、bstrieが私に提示したServerOptsの例では：

fn main() {
  use O = html::StartServerOptions;
  ...
  html::start_server(O{port: 10088});
}

@pnkfelix私は好きです

struct Foo {
   x: int = 10,
   y: float = 1.0
}

構文ですが、賢明な強制引数（残念ながら名前は付けられていません）を取得するために必要ではないと思います。強制引数を個別に渡すだけです。

struct FooOptions { ... }
static default: FooOptions = FooOptions { ... };
fn foo(compulsory: int, required: uint, necessary: float, optionals: FooOptions) { ... }

FWIW、デフォルト値のアイデアを持つ構造体も好きです。 私はそれが次のショートカットになると思います：

struct Test {
    m: int,
    y: int
}

static DEFAULT: Test = Test{m: 10, y: 15};

Test{y: 5, ..DEFAULT}

定義内の構造体のデフォルトも気に入っています

その構文で解析することもできますが、実際には使用されていません。タイプチェッカーのソースなどを回避する方法がまだわかりません。

おそらく、デフォルトのメカニズムがすでに存在するという事実により、実装が少し簡単になる可能性があります。

再。 匿名の構造体は元々持っていたと思いますが、「奇妙な相互作用のために」それらを削除する必要がありましたか？
私は両方のメカニズムを利用できるようにしたいと思います。 おそらくパラメータ構造体は_keyword_引数の必要性を軽減しますが、c ++のような末尾のデフォルトは依然として便利です

参考のため -
http://www.parashift.com/c++-faq-lite/named-parameter-idiom.html
笑-興味深いが本当のキーワード引数は、このような定型的な重いハックの必要性を回避するでしょう

再。 匿名の構造体は元々持っていたと思いますが、「奇妙な相互作用のために」それらを削除する必要がありましたか？

元々、すべての構造体タイプは構造体でした。 特性との厄介な相互作用のために、それらは削除されました（名目上の構造体タイプに置き換えられました）。

構造体定義のアイデアのデフォルト値が好きです。 これは理解しやすいようで、少なくとも構造体を構築するときにすべてのフィールドを列挙する必要がありません。これは、新しい「オプション」フィールドが追加されたときにすべての呼び出しサイトを次のように変更する必要があることを意味するため、「オプション」タイプの構造体の問題です。 0 / None / etcに初期化します。

Perl（デフォルトはアドホックパターン）、Python 2（ foo() takes at least 2 arguments (2 given)取得できる）、およびPython 3（デフォルトなしで名前付きのみの引数を持つことができる）から来て、私は謙虚に提案します：追加関数の最後の引数として構造体を宣言できるようにするための砂糖の_teeny_ビット。ただし、呼び出し元は構造体フィールドを_インライン_します。

例えば

impl int {
    struct FromStrOptions {
        radix: uint = 10
    }
    fn from_str(s: str, opts: FromStrOptions) -> int {
        // ...
    }
}

int::from_str("4", radix: 10);

利点：

• 関数定義の新しい構文はありません。これは、呼び出し元がどのように呼び出すかを実際に気にする必要はありません。 これは、 doブロックを渡す方法に似ています。これは、純粋に呼び出し元の懸念事項です。 （構造体であるが、kwargsに使用されることを意図していない最後の引数がある場合、オプトイン/オプトアウトする方法が必要ですか？誰か気になりますか？誰もdo気にしないと思います
• バイナリレイアウトやC呼び出しのセマンティクスなどは、まだかなり明確に定義されています。
• 型またはアリティによるオーバーロードは、いつか実装するのが難しくなりません。ただし、最後の引数の型が型のオーバーロードに寄与することはありません。 可変引数が発生した場合でも、干渉するべきではありません。
• 同じデフォルトのセットを複数の関数で再利用できます。
• 無料で**kwargsようなもの：構造体を作成し、代わりに位置引数として渡すだけです。
• 必須のキーワード引数は当然これから外れます。構造体にデフォルトを指定しないでください。名前で_something_を渡す必要があります。
• 名前で位置引数を渡すときに、奇妙な混乱はありません。 あなたはそれをすることはできません。

短所：

• 少し魔法。 しかし、 5を渡して、関数のargspecから型を推測するだけだと思います。
• 既存のdoイディオムとどのように相互作用するかは不明です。 _written_の最後の引数である必要があると言うのは簡単かもしれません。つまり、 do使用した場合にのみ、最後から2番目の引数として機能します。

FWIW int::from_str("4", radix: 10)は、以前に提案された、型帰属演算子としての:使用と競合します。

ASCIIによって失敗した呪い。

int::from_str("4", radix☃ 10)

キーワード引数に=を使用することに投票しますが、部分式内でのCの割り当てのアイデアを禁止します。それがcのような構文にどのように適合するかの可能な例？

これを実装する方法をブレインストーミングする場所はありますか？引数の数に基づく関数のオーバーロードのように、変数arguemntスタイルを内部的に実装できるかどうか疑問に思いました（引数の数が関数名に後置されているかのように..）

これについては昨夜の毎週の

関数宣言/呼び出しフォームをさらに複雑にするのは良くないこと、そして以前のコメントで示唆され

チームはまた、これを何らかの方法で解決することは、1.0リリースの優先事項ではないと判断しました。 プロジェクトリーダーの@brsonは、このタスクのプロトタイピングは1.0以降（1.1リリースなど）に任せることを提案しました。

これは、すべての貢献者への強力なヒントです。好きなものをすべてハックしますが、1.0がリリースされるまで、このバグのプルリクエストやr +を送信しないでください。

伝承、Rustは素晴らしい言語です。 それはとても多くのことを正しく行います、それは面白くさえありません。 しかし、この機能をポスト1.0に延期するのは間違いだと思います。

詳しく説明させてください。

優れたAPI設計のために、デフォルトの関数引数は_クリティカル_です。 それらがないため、他の方法ではより単純なAPIになるものが複雑になります。 stdライブラリの例：

• オプションでセパレータを使用するconcat代わりに、 concatとconnect 。
• split_iterとsplitn_iter split_iterは、オプションのcount使用してsplit_iterを超えています。 rsplit_iterとrsplitn_iter同じです。

その他。

デフォルトの引数で削除できるこれらの余分な関数名をすべて持つと、認知的負荷が不必要に増加します。 ユーザーは、1つではなく2つ（またはそれ以上）の名前を知っている必要があります。

デフォルトの引数が1.0以降に延期された場合、下位互換性のため、stdライブラリ内のこれらの関数を削除できません。 つまり、将来デフォルトの引数が追加され、関数の「バニラ」バージョンが他のバリアントの作業を実行できるようになったとしても、古いバリアントは残り、開発者は誰かが確実に使用するため、それらについて知る必要があります。たとえ間違っていたとしても、それら。

そのため、余分な認知的負荷は_永遠に_残ります。

[注：パラメーター型ベースの関数のオーバーロードについても同じ議論をすることができます（現在の特性ベースの回避策は煩雑すぎて、stdライブラリ関数はそれを使用しません）が、この問題はその議論の場ではありません。]

Rustの開発者、Rustに取り組み、素晴らしいものにしてくれてありがとう！

私は「遠い未来」のマイルストーンを追加して、コアチームの私たちがこの問題に2番目の時間を費やしている人に伝えたいという極端な落胆を強調しています。 今すぐRustに貢献したい場合は、マイルストーン1（明確な定義）の41の未解決のバグの1つに取り組んでください。

https://github.com/mozilla/rust/issues?milestone=12&state=open

またはマイルストーン2の104の未解決のバグの1つ（下位互換性）：

https://github.com/mozilla/rust/issues?milestone=13&state=open

またはマイルストーン3の68の未解決のバグの1つ（ある時点で合意した機能はRust 1.0をリリースするために重要です）：

https://github.com/mozilla/rust/issues?milestone=14&state=open

または、これらのバグの1つにコメントして、説明を求めたり、進歩を遂げる方法を提案したりすることもできます。 これは213個のバグから選択できます。 この時点でそれらのいずれかを進歩させることは、この問題よりもRustにとってはるかに価値があります。 そして、これらのバグの1つを閉じることができる人は誰でも、私たちの最大の感謝を持っています。

コアチームにはもっと重要なことがあることがわかりますが、「極端な落胆を伝える」のは残念なことのようです:(
valloricsコメントに+1。 ネーミングは難しいです、ドキュメントを掘り下げて、より多くの名前を学ぶことは不快です..; デフォルトのargs / overloardingにより、簡単になります。 キーワード引数を使用すると、これについてC ++を超える機会があります。 （githubに投票してもらいたいのですが、ここでもう少し怒鳴る代わりに+1を押すことができます笑）

@Valloric私は（前に言ったように）完全に同意し、API設計に影響を与えるため、rustコアチームがオプションの引数を再検討するか、少なくとも再検討することを本当に望んでいます。 名前付きargsは、ほとんどが呼び出しサイトに影響を与えるため、確実に待機できます（もちろん、argsに名前を付けると、argsの名前はAPI設計の一部になるため、わずかな影響はありますが、argsが名前を付けた場合、BCを破るような影響はありません。名前付き引数が導入されるとクリーンアップされます）。

これが優れた言語機能になるというコンセンサスはありません。 また、名前付き/デフォルトのパラメータについてすべての詳細が練られた具体的な提案はありません。 非常に本質的でない構文糖衣を夢見る前に修正または削除するコア言語機能の既存のセットがあるため、1.0では発生しません。

「夢見る」とは、何か空想的なもののように聞こえますが、これらの機能は他の言語で証明されています。 シンタックスシュガーだけでなく、ナビゲートする必要のあるコードの量を減らし、学習する必要のある記号の数を減らします。

非常に本質的でない構文糖衣を夢見る前に修正または削除するコア言語機能の既存のセットがあるため、1.0では発生しません。

修正/実装する必要のある他の言語機能がそれほど重要ではないと言っているのではありません。 彼らはおそらくそうです。 しかし、それはどちらでもありません。 私が言っているのは、この機能がない場合はstdライブラリのAPIの品質に影響を与えるため、この機能は（他の機能に加えて）1.0で強く検討する必要があるということです。

これはおそらく物議を醸す意見ですが、IMOプログラミング言語は、それらのコア機能よりも、提供するAPIによって生きて死んでいきます。 Pythonの「バッテリーが含まれている」stdライブラリは言語全体を販売しました。 CPANはPerlを存続させます。 .Netは、C＃コードの記述を素晴らしいものにします。そして、スライスされたパン以来、LINQは最高のものです。 C ++の最大の失敗の1つは、優れた標準化されたAPIの欠如です。 等。

APIは言語の成功に不可欠であるため、_good_APIの作成を可能にする機能を「必須の構文糖衣構文」として破棄しないでください。

@dobkeratops ：_dreaming up_と言うことで、完全な提案がなされていないことを強調しようとしているので、意思決定の段階ではありません

この議論は非生産的です。 それが誰かの時間を無駄にするのを防ぐために、私は問題を閉じるつもりです。 誰かが今から1年後、またはそれ以降にそれを再開したい（または新しい問題を開始したい）場合は、それで問題ありません。

誰かがほとんどすべての詳細（文法、セマンティクス）を解決した提案を思いついた場合は、それをメーリングリストに投稿することをお勧めします。 これを行う特定の方法が_正しい方法_であるというコンセンサスに達した場合は、問題を開いて、 once関数などのフラグの背後にある実験的な機能として実装するのが理にかなっています。

私は2番目の@ thestinger-誰か（または少数の人々）が完全な提案を持っている場合、または議論のためにいくつかの明確に綴られた空白のスポットがある提案を持っている場合、その人がそれを実行するのが適切でしょうメーリングリストで。 それは私たちがその提案を実行するという約束ではありませんが、アイデアを形式化し、それが他の言語機能とどのように相互作用するかを説明する作業を行うと、提案の価値が大幅に高まります。

@thestinger @catamorphism心を開いてくれてありがとう！ 時間があれば、提案書を作成してrust-devに送信します。

この機能について議論し、明確な仕様を書くためにパッドを作成しました： https ：

これを再開します。 それは優先事項ではありません-やらなければならないことがすでに多すぎます-しかし、それは人々が望んでいる機能であり、それは完全にテーブルから外れているわけではありません。 この件に関する会話を止めたくありません。

@brsonありがとうございます！

イーサパッドへのリンクを使用して元の問題を編集しました。

こんにちは。
パッドの作成以来、多くの設計提案、質問、問題などによって完成されています...
そこで、ディスカッションパッドを「要約」するための2番目のパッドを作成しました。このパッドは、機能要求を正確に説明するために使用されます。
ここにURLを埋める： https ：

@KokaKiwiすべてのパッドが空になりました。 内容はどこに行きましたか？

@cmr 、私は推測します：

警告：このパッドは、編集せずに30日が経過すると削除されます。 これが起こった後、パッドを回復する方法はありませんので、注意してください！

：しかめっ面：

私は実際にMozillaEtherpadインスタンスで作成したパッドを検索しています（このケースを防ぐため）が、履歴に見つからないため、ここにリンクを公開するのを忘れました:(

@cmr @huonw @KokaKiwi 、ブラウザの履歴にある2つのリンクは次のとおりです。

https://etherpad.mozilla.org/CQEDa85jLX
https://etherpad.mozilla.org/78FA1bozLd

@dramそれが私が探していたものです！ ありがとう：スマイリー：
たぶん、問題は新しいリンクで編集する必要があると思います。

（編集済み）

私はこれを追加する意味のあるものは何もありませんが、これは私が言語にもっと時間を費やす前に私が注意深く見ているものの1つです。 この機能を備えた言語（Objective-CおよびPython）から来ているので、名前付きパラメーターは、他の人のコードをより読みやすくする方法のため、生産性を間接的に大幅に向上させると思います。

具体的な提案は、新しいRFCプロセスを通じて行う必要があります： https ：

ここには相反するアイデアや多様な会話のスレッドが多すぎて、有用なディスカッションエリアにはなりません。