Rust part13

**デフォルトの名無しさん** · 2021/11/07(日) 10:04:59.35

公式
https://www.rust-lang.org/
https://blog.rust-lang.org/
https://github.com/rust-lang/rust

Web上の実行環境
https://play.rust-lang.org

日本語の情報
https://rust-jp.rs/

※Rustを学びたい人はまず最初に公式のThe Bookを読むこと
https://doc.rust-lang.org/book/

※Rustのasyncについて知りたければ「async-book」は必読
https://rust-lang.github.io/async-book/

※C++との比較は専用スレへ
C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

※次スレは原則>>980が立てること

前スレ
Rust part12
https://mevius.5ch.net/test/read.cgi/tech/1629813327/

**デフォルトの名無しさん** · 2021/11/22(月) 19:36:28.33

なるほどね

**デフォルトの名無しさん** · 2021/11/22(月) 19:55:09.41

>>97
それだとT: From<i32>という無関係で不要な強い条件を満たさないといけないため
例えば>>93の型Xでは動かないね
シンプルにZero、One、Add、PartialOrdだけで実装したほうが良さそう

**デフォルトの名無しさん** · 2021/11/22(月) 20:04:43.45

C++じゃないんだから不毛な型パズルはやめろ

**デフォルトの名無しさん** · 2021/11/22(月) 20:25:52.53

C++よりマシ

**デフォルトの名無しさん** · 2021/11/22(月) 20:56:45.47

意味のない例で延々とよくやるわ

**デフォルトの名無しさん** · 2021/11/22(月) 21:02:15.85

カスタムな型ならRangeよりイテレータ対応が先

**デフォルトの名無しさん** · 2021/11/22(月) 21:09:17.05

StepがunstableなのはさておきFromLiteralみたいなトレイトがあるとZeroやOneの出番が減ってうれしいのかね
T: FromLiteralの時に整数リテラルがT型の値として解釈されるようになるようなイメージ

**デフォルトの名無しさん** · 2021/11/22(月) 21:58:50.69

try_into()でできるよ

**デフォルトの名無しさん** · 2021/11/22(月) 22:09:34.28

言葉足らずでしたね

struct Foo;
が FromLiteral を実装しているときに
let n: T = 123;
というコードを書くとコンパイラが
let n = T::from_literal("123");
といったコードに変換してくれるイメージ

from_literalはconst fnにできてコンパイル時にエラー検出できるとベター

**デフォルトの名無しさん** · 2021/11/22(月) 22:10:11.00

>>106
TはFooの間違い

**デフォルトの名無しさん** · 2021/11/23(火) 07:57:08.78

ねこ

**デフォルトの名無しさん** · 2021/11/23(火) 10:28:33.41

https://github.com/rust-lang/team/pull/671
Coreチームがクソだからやめたった、ってこと？

**デフォルトの名無しさん** · 2021/11/23(火) 13:56:03.32

const fnが言いたいだけやろ、だれが＝演算子でcopyでもなく、言語上ないことになってるコンストラクタでもなく
そんな特異なトレイトを勝手に呼ぶのが嬉しいねん、なにがバター犬や

**デフォルトの名無しさん** · 2021/11/23(火) 14:58:36.02

>>110
= が特殊な振る舞いをするのではなくて
整数リテラルが組み込み整数型についてgenericな数値になるという振る舞いを
FromLiteralを実装した型に広げようという案のつもりです

**デフォルトの名無しさん** · 2021/11/23(火) 20:05:14.41

m..nをiter::Step使わず素直にPartialOrd + One + Addだけで実装してくれれば汎用的で分かりやすいと思う

struct Range<T> {
　start: T,
　end: T,
}
fn range<T>(start: T, end: T) -> Range<T> {
　Range { start, end }
}
impl<T: Clone + PartialOrd + One + Add<Output=T>> Iterator for Range<T> {
　type Item = T;
　fn next(&mut self) -> Option<T> {
　　if self.start < self.end {
　　　let result = self.start.clone();
　　　self.start = self.start.clone() + T::one();
　　　Some(result)
　　} else {
　　　None
　　}
　}
}
fn main() {
　let n :Vec<u8> = range(1, 5).collect();
　let x :Vec<X> = range(X::new("x"), X::new("xxxxx")).collect();
　println!("{:?}", n); // [1, 2, 3, 4]
　println!("{:?}", x); // [X("x"), X("xx"), X("xxx"), X("xxxx")]
}
>>93のX型でも動いたよ

**デフォルトの名無しさん** · 2021/11/23(火) 20:38:59.43

特徴もないリテラルを勝手に解釈するとかあり得んわ
現状だって0b0011u32とか0x80u32とか書いてるのに、型定義が横にあるからそれでコンパイル時に
パース処理したいなんてそんな都合の良い言語ちゃうだろ、Raw stringのr"123"とか、Raw bytesとか
とも違うし、確かにfrom_strが"123"を解釈するけどやるにしても、let x: i32 = "123";が通ってから。
でもコンパイル時とはいえ自動型変換に見えるコードは承認しないと思うし、直行性も下がる
こんな場末の酒場みたいな所で言ってもコミッターどころかforと高階関数で揉める駄スレにどうこう出来る内容ちゃう

**デフォルトの名無しさん** · 2021/11/23(火) 20:58:16.83

>>112
数値だからAdd+Oneが成り立つわけで
型Xとか何の意味もないぞ

**デフォルトの名無しさん** · 2021/11/23(火) 22:14:31.32

>>114
でも現実のプログラミングでは数値を生で使うよりも
struct Counter { usize } とか
struct Age { usize } とか
struct XxxLength { usize } とかにして
型が異なることをはっきりさせて安全に使いますよね
そして付加情報があればstructのフィールドが複数になることもあったり
あるいはstruct std::time::Durationのようにnanoからsecまで扱えるようにしてもAddをimplして使いますよね
つまり生の数値だけを対象にしていては視点が狭いと思うのです

**デフォルトの名無しさん** · 2021/11/23(火) 22:15:57.50

>>115の{ }は( )の誤記ですw

**デフォルトの名無しさん** · 2021/11/24(水) 03:12:15.58

Stepがstable入りしたら要らなくなる話になにとんでもない破壊的変更を持ち出しているんだ

**デフォルトの名無しさん** · 2021/11/24(水) 03:25:07.43

Age型をn.times().for_each()
Length型をn.times().for_each()
Duration型をn.times().for_each()

ジェネリックw

**デフォルトの名無しさん** · 2021/11/24(水) 05:02:23.28

>>118
timesより>>112のm..n rangeイテレータが汎用的でいいんじゃね？

**デフォルトの名無しさん** · 2021/11/24(水) 15:22:53.32

>>119
times()ですら無駄なのに>>112とかありえないよ
無価値どころか害悪レベルなんだけど

**デフォルトの名無しさん** · 2021/11/24(水) 17:05:44.23

>>117
コンパイラや標準ライブラリの変更で型推論の結果が変わることは破壊的変更扱いされなかったっけ

**デフォルトの名無しさん** · 2021/11/24(水) 17:26:56.67

>>106
なんとなく分かりましたがいきなりコンパイラが自動変換の前に現状で
例えばまずは整数型を例に絞ってやるとして
trait IntegerCompatible {
　type Integer;
　fn into_integer(&self) -> Self::Integer;
　fn from_integer(n: Self::Integer) -> Self;
}
こんな感じのトレイトにして
まずは利便性のために整数型自体に自分を返すよう実装しておいて
macro_rules! integer_compatible {
　($($t:ty)*) => ($(
　　impl IntegerCompatible for $t {
　　　type Integer = $t;
　　　#[inline]
　　　fn into_integer(&self) -> Self::Integer {
　　　　*self
　　　}
　　　#[inline]
　　　fn from_integer(n: Self::Integer) -> Self {
　　　　n
　　　}
　　}
　)*)
}
integer_compatible! { i8 i16 i32 i64 i128 isize u8 u16 u32 u64 u128 usize }
あとは今はコンパイラ支援がないので
使う時に自分でinto_integerして計算などして結果をfrom_integerする感じですかね

**デフォルトの名無しさん** · 2021/11/24(水) 17:39:27.77

>>122の続き
実際に使ってみる具体例として面倒なので>>112をそのまま使うと
struct Range<T> {
　start: T,
　end: T,
}
このあたりはそのまま使うとして
fn range<T>(start: T, end: T) -> Range<T> {
　Range { start, end }
}
実装部分ではジェネリックT型にOneやAddなどを求められていたのを
CloneとIntegerCompatible要求だけに変えて整数型IにOneやAddなどを移動
impl<T, I> Iterator for Range<T> where
　T: Clone + IntegerCompatible<Integer=I>,
　I: Copy + PartialOrd + num::One + std::ops::Add<Output=I>, {
　type Item = T;
　fn next(&mut self) -> Option<T> {
　　if T::into_integer(&self.start) < T::into_integer(&self.end) {
　　　let result = self.start.clone();
　　　self.start = T::from_integer(T::into_integer(&self.start) + I::one());
　　　Some(result)
　} else {
　　　None
　　}
　}
}
今はコンパイラ支援がないので手動変換ですが自動もしくは簡便な記法に出来そう
あと整数型にはいちいちOneやAddやPartialOrdを書かなくても済むように出来そう

**デフォルトの名無しさん** · 2021/11/24(水) 17:47:29.36

>>123の続き
念のため実際に使う時にどうなるかと使えるかを確認すると
let n :Vec<u128> = range(3, 7).collect();
println!("{:?}", n); // [3, 4, 5, 6]
もちろん整数型自体は使えるのは当たり前なのでLength(usize)で使う場合
#[derive(Debug,Clone)]
struct Length(usize);
impl IntegerCompatible for Length {
　type Integer = usize;
　fn into_integer(&self) -> Self::Integer {
　　self.0
　}
　fn from_integer(n: Self::Integer) -> Self {
　　Length(n)
　}
}
このIntegerCompatible定義はこのような単純形ならマクロ化で出来そうですね
let v :Vec<Length> = range(Length(3), Length(7)).collect();
println!("{:?}", v); // [Length(3), Length(4), Length(5), Length(6)]
そして当然ながら動きました

**デフォルトの名無しさん** · 2021/11/24(水) 17:56:43.20

>>124の続き
あとは>>93に出てきた変なX型ですね
#[derive(Debug,Clone)]
struct X(String);
impl X {
　fn new(s: &str) -> Self {
　　if !s.chars().all(|c| c == 'x') {
　　　panic!("not x");
　　}
　　X(s.to_string())
　}
}
と定義はそのまま使っておきます
あとはOneやAddの実装はをせずにIntegerCompatibleだけ実装
impl IntegerCompatible for X {
　type Integer = usize;
　fn into_integer(&self) -> Self::Integer {
　　self.0.len()
　}
　fn from_integer(n: Self::Integer) -> Self {
　　X::new(&std::iter::repeat("x").take(n).collect::<String>())
　}
}
このような特殊例のみIntegerCompatible実装のマクロ化は無理ですね
let v :Vec<X> = range(X::new("xxx"), X::new("xxxxxxx")).collect();
println!("{:?}", v); // [X("xxx"), X("xxxx"), X("xxxxx"), X("xxxxxx")]
当然ですがX型についても動きました

**デフォルトの名無しさん** · 2021/11/24(水) 18:18:05.49

誰も見てねーから別のところでやれ

**デフォルトの名無しさん** · 2021/11/24(水) 19:13:18.31

話題がないんだもん
なんか話題を提供してくれ

**デフォルトの名無しさん** · 2021/11/24(水) 23:19:00.01

結局Derefみたいにコンパイラが自動的に適用して変換してくれればそのintoやfromをプログラムには書かなくて済むんやろ

**デフォルトの名無しさん** · 2021/11/25(木) 23:08:27.91

ファイルを開く操作って普通に考えたらFile::open_ほにゃらら()みたいなメソッドにOpenOptionsを渡すほうが自然だと思うんですが
OpenOptions::open()みたいな方法を取ってるのってどういう理由からなんでしょうか？

**デフォルトの名無しさん** · 2021/11/25(木) 23:59:01.72

>>129
・その方がメソッドチェーンで見やすい
・複雑な構造体を用意してそこに様々な値をセットして指定するインターフェースは非常に大変
・そのうえOS毎に違う部分もある

**デフォルトの名無しさん** · 2021/11/26(金) 00:22:31.18

>>129
Rustは関数定義でデフォルト値のあるオプション引数をサポートしてないから
オプション引数的な使い方をしたい場合はビルダーパターンを使うのが一般的

File::options().read(true).create(true).open("foo.txt”);みたいな使い方になる

**デフォルトの名無しさん** · 2021/11/26(金) 09:37:38.31

うーん
ダサいな
もっときれいにならんの？

**デフォルトの名無しさん** · 2021/11/26(金) 09:50:01.95

メソッドチェーンって過去の遺物だよね？
バグの温床だし
長いとどこかで消し忘れや二重指定が出て本人が気が付かなくなる
長くなっただけで破綻するんだからおかしい

**デフォルトの名無しさん** · 2021/11/26(金) 10:00:30.74

>>133
一般的に今どきのプログラミング言語は全てメソッドチェーンが主流
もしかしてメソッドチェーンを使わない古い言語使いの方ですか？

**デフォルトの名無しさん** · 2021/11/26(金) 10:06:22.27

パイプライン演算子大好きとかLisp方面から来た人とかなのかも……

**デフォルトの名無しさん** · 2021/11/26(金) 10:12:22.08

え？メソッドチェーンってjqueryが流行ってたころの名残でしょ？
10年ぐらい前

メソッドチェーンなんて書いててだるいだけ

**デフォルトの名無しさん** · 2021/11/26(金) 10:21:37.95

>>136
JavaScriptも今は関数型プログラミングが主流へと変わりメソッドチェーンだし外部ライブラリを使うインタフェースもメソッドチェーンがよく使われる
そしてRustも同様
どこの古い世界から来たお客さんですか？

**デフォルトの名無しさん** · 2021/11/26(金) 10:34:43.95

メソッドチェーンって関数型由来ではないし

**デフォルトの名無しさん** · 2021/11/26(金) 11:18:59.37

>>133
ビルダーは二重指定しても問題ない
消し忘れはどういう指定方法でも発生するからテストで防ぐ以外ないよ

テスト書かない文化の人？

**デフォルトの名無しさん** · 2021/11/26(金) 11:23:55.78

>>135
パイプ演算子も同じ問題抱えてるし
Lispでも今はthreadマクロで処理順に書く

**デフォルトの名無しさん** · 2021/11/26(金) 11:31:53.80

>>140
はえ～、そうか勉強になったわ

**デフォルトの名無しさん** · 2021/11/26(金) 11:44:41.28

>>139
二重指定は一方でtrue一方でfalse指定しているパターン

**デフォルトの名無しさん** · 2021/11/26(金) 12:05:35.16

>>132
どうやったら綺麗なのか参考のため教えて
Rustじゃなくて他の言語でも
仮想の言語でもいいよ

**デフォルトの名無しさん** · 2021/11/26(金) 12:25:05.02

通常のCのオープン関数のほうが100倍キレイで簡潔で合理的だと思うが個人差はあるんだろうな

File::options().read(true).create(true).open("foo.txt”);

これを書くときにリードがtrueだな、createもtrueだな、そしてファイル名はfoo.txtだと言う思考順序で
コード書くとは思えないんですよ常識的に

**デフォルトの名無しさん** · 2021/11/26(金) 12:29:19.27

これが美しいと言う人はそれこそ逆ポーランド次元から来た異次元人だと思うよ

**デフォルトの名無しさん** · 2021/11/26(金) 12:40:54.22

なかなか極端な例を出してきたな……

**デフォルトの名無しさん** · 2021/11/26(金) 12:43:09.59

おまいら日本語否定ですか。

>>144は設計が悪いんじゃない？

File::options().readwrite().newfile().open("foo.txt”);

なら自然だろ。
>>144

**デフォルトの名無しさん** · 2021/11/26(金) 12:51:53.22

逆ポーランド人現る

**デフォルトの名無しさん** · 2021/11/26(金) 12:53:26.61

ファイルを開こうと思うときにoptions型から思考がスタートする人は天才なんだろうな
それか飼いならされた人

**デフォルトの名無しさん** · 2021/11/26(金) 12:57:20.12

言語否定じゃなくてライブラリ設計がおかしい
実用無視の人が設計するとこうなる

**デフォルトの名無しさん** · 2021/11/26(金) 12:58:29.05

File::open_with_options("foo.txt", &OpenOptions::new().read(true).create(true));

どっちが良いとか悪いとかじゃないと思うがなあ

**デフォルトの名無しさん** · 2021/11/26(金) 13:13:18.47

美しくないだろ普通に

**デフォルトの名無しさん** · 2021/11/26(金) 13:13:45.37

OpenOptionsって名前で明らかに｢ファイル開く時のオプションですよ｣って名前なのにファイル開く操作まで持ってるから気持ち悪いんだよな
同じモジュールでディレクトリはDirBuilderとかあるんだから普通にFileBuilderとかにすりゃええやんとか思っちゃうけどなんか理由があったんかね

**デフォルトの名無しさん** · 2021/11/26(金) 13:23:36.09

確かに他だったらoptionのインスタンスを作ってopenに食わせる感じだな
それもどうかと思うけど
ほぼ定数みたいなものをわざわざ作って食わせるなんて

**デフォルトの名無しさん** · 2021/11/26(金) 14:04:50.29

慣れない人にとっては分かりにくいAPIにならざるを得ないのは確か

ただ他の言語でオプション引数やオーバーロードが2桁あるのが当たり前になってるようなライブラリを見るとそれぞれ一長一短あるなとは思う

**デフォルトの名無しさん** · 2021/11/26(金) 14:15:29.08

>>154
associated constくらい用意してもらってもいいかもね

**デフォルトの名無しさん** · 2021/11/26(金) 14:20:28.16

>>153
OpenOptionsはrust1.0以前からあるものなのでその頃はビルダーのイディオムがなかったのだと思う
DirBuilderはrust1.6で追加されたものなので比較的新しい

**デフォルトの名無しさん** · 2021/11/26(金) 14:57:24.65

> 通常のCのオープン関数のほうが100倍キレイで簡潔で合理的

さっぱりわからんけどｗ
別に
File::options().readwrite().newfile().open("foo.txt”);
がいいとも悪いとも思わんし
cのopenがいいとも悪いとも思わん
どんな素晴らしいopen見せてくれるのかと思ったらガッカリした

**デフォルトの名無しさん** · 2021/11/26(金) 15:03:20.08

OpenOptionsが分かりにくいってのはそのとおりだと思うし、実際みんなそう思ってるみたいで
ちょうどFile::optionsにするRFCが通るところだよ

**デフォルトの名無しさん** · 2021/11/26(金) 16:18:02.52

>>159
stabilizeのPRが10日前に取り込まれたから1月にはリリースされそう

**デフォルトの名無しさん** · 2021/11/26(金) 18:16:06.66

>>158
FILE * fopen(const char * filename, const char * mode);

こっちの方が100倍良い

**デフォルトの名無しさん** · 2021/11/26(金) 19:18:40.42

>>161
それはfopenの仕様(引数の意味とか)を知っているのが前提だからなぁ。
filenameとmodeの順番を間違えたら読み間違える。
メソッドチェーンと比較するなら名前付き引数のメソッド呼び出しじゃない？
あるいはインテリセンス環境下という条件付きか。

**デフォルトの名無しさん** · 2021/11/26(金) 19:21:46.75

>>161
ほんそれ

**デフォルトの名無しさん** · 2021/11/26(金) 19:26:21.35

仮想のコードで例が適切かどうかわからないけど

File::options().readwrite().newfile().read().open("foo.txt”)

と書いて直後で書き込めねえええええよと叫ぶよりfopenの方がいいだろ;

**デフォルトの名無しさん** · 2021/11/26(金) 19:37:54.04

あ、ミスった

それはさておき例のメソッドチェーン見ても瞬時に不安しかよぎらない

readwrite（) が中で read(true).write(true) してるとして
readonly() が中でread(true)しかしてないんじゃないかとか不安

**デフォルトの名無しさん** · 2021/11/26(金) 19:47:03.96

>>162
> 名前付き引数のメソッド呼び出しじゃない？

俺も最初はそう言う話が出てくるのかとおもったら
cのopenを有りがたがってる奴が出てきて呆れた

**デフォルトの名無しさん** · 2021/11/26(金) 20:09:04.42

>>134
メソッドチェーンと関数チェーン|パイプラインが区別できてないんでは？
メソッドチェーンってレシーバの記述を省略できるとか文の数が減るとかでしかないでしょ。

**デフォルトの名無しさん** · 2021/11/26(金) 20:37:35.34

>>166
fopenとゴミみたいなメソッドチェーン
どっちがバグの温床だ？

**デフォルトの名無しさん** · 2021/11/26(金) 20:42:02.78

cのfopenはメソッドチェーンより簡潔だ

本当は他の言語のenumでいいんだけど

Open("rust.txt",FileMode.Open, FileAccess.Read)
これでバグは出ない

**デフォルトの名無しさん** · 2021/11/26(金) 20:55:25.49

そんなに変わらへんやん、むしろuseで引き込む名前が増えて美しくないやん

**デフォルトの名無しさん** · 2021/11/26(金) 21:02:27.39

foo(true, false, true, false) や foo(None, None, None, Some(true)) みたいな呼び出しよりは100倍マシ

**デフォルトの名無しさん** · 2021/11/26(金) 22:47:08.22

ところでreadwrite()とかnewfile()ってなんですか？

**デフォルトの名無しさん** · 2021/11/27(土) 00:09:21.90

OpenOptionsの名称問題はともかく
なぜメソッドをチェーンさせているかというと理由は明白で
OpenOptionsExtトレイトをuseすると使えメソッドが拡張されて.mode()などが使えるようになるからだよ

**デフォルトの名無しさん** · 2021/11/27(土) 00:15:29.99

パイプ演算子は |> いつ実装されるの？

**デフォルトの名無しさん** · 2021/11/27(土) 00:19:05.68

どうせ上のtimes()トレイト君でしょ

**デフォルトの名無しさん** · 2021/11/27(土) 00:42:49.16

チェーンの話なら、出来るだけチェーン派が多いけど.NETのLINQみたいになったら嫌？
それとも歓迎？LINQ形式のほうが分かりやすい。前の高階関数の話もそうだけど…
OpenOptionsはなんでもかんでもトレイトの弊害の気もする
articles =
　　from a in articles
　　orderby a.published descending
　　select new article_st;
https://github.com/StardustDL/Linq-in-Rust
let e: Vec<i32> = linq!(from p in x.clone(), where p <= &5, orderby -p, select p * 2).collect();
このプロジェクトはcloneしてしまうところがダサいが、MSが参画しているということはありうるわけで

**デフォルトの名無しさん** · 2021/11/27(土) 00:54:31.43

>>173
元がこうだもんな
int open(const char *pathname, int flags);
int open(const char *pathname, int flags, mode_t mode);
そしてunix以外にも対応するために
std::os::unix::fs::OpenOptionsExtへ分けたのだろう
このメソッドチェーンビルダー方式以外のAPIでは詰む

**デフォルトの名無しさん** · 2021/11/27(土) 05:50:15.37

>>176
LINQはSQL風になる糖衣構文だからちょっと違うんちゃう。Rustに導入されても他の世界感と異質だし……。
個人的にはあれがSQL屋以外に直感的とは思えないw

**デフォルトの名無しさん** · 2021/11/27(土) 09:55:26.18

>>174
rustは第一引数がselfの場合にメソッドのレシーバーになるのだから、実質パイプライン

**デフォルトの名無しさん** · 2021/11/27(土) 11:01:40.71

それはElixirと同じ「なんちゃってパイプライン」でメソッドチェーンが実現できるというだけでは。
ここで欲しいと言われているのは大元のF#のように自由関数やその部分適用が使えるパイプラインのことだろう。

**デフォルトの名無しさん** · 2021/11/27(土) 12:26:31.88

自由関数？

**デフォルトの名無しさん** · 2021/11/27(土) 14:14:35.41

第一引数がselfとかじゃないやつのことじゃね

**デフォルトの名無しさん** · 2021/11/27(土) 15:58:50.40

自由関数ってなんだっけ？
自由変数ならわかるんだけど

**デフォルトの名無しさん** · 2021/11/27(土) 15:59:45.03

定義を示してほしいわな
F#界隈にもRust界隈にも無い用語だし

**デフォルトの名無しさん** · 2021/11/27(土) 16:36:46.11

何気なく使ってたけど調べてみたらC++用語だったか。しかも日本じゃ「フリー関数」という表記の方が一般的なんだな。
メンバー関数(メソッド)ではない素の関数ということで。

**デフォルトの名無しさん** · 2021/11/27(土) 17:08:07.51

その意味ならElixirは自由関数も部分適用も使えると思うが・・・

**デフォルトの名無しさん** · 2021/11/27(土) 17:20:05.91

そっちか。
Elixirのパイプラインの使用例でよく見る形式が部分適用とは違うんで使えないものと思っていた。すまん。
部分適用は別の表記になるんだな。

**デフォルトの名無しさん** · 2021/11/27(土) 17:59:12.10

C++でもフリー関数と言われたら free() のこと思い浮かべそうだが

**デフォルトの名無しさん** · 2021/11/27(土) 18:21:56.04

>>178
そうは言っても現状の下のこれが直感的に分かり易いとは思えないけど、、LINQはSQLとは関係ないよ。
whereとかselectがそれに見えるけど、言語的には直行性を高めた統合クエリなだけ
let mut y: Vec<i32> = x.clone().filter(|p| p <= &5).collect();
y.sort_by_key(|t| -t);
let y: Vec<i32> = y.into_iter().map(|t| t * 2).collect();

**デフォルトの名無しさん** · 2021/11/27(土) 19:30:03.08

>>189
どこが見にくいのか具体的に教えて
use itertools::Itertools;
let y: Vec<i32> = x
　.filter(|p| p <= &5)
　.sorted_by_key(|t| -t)
　.map(|t| t * 2)
　.collect();

**デフォルトの名無しさん** · 2021/11/27(土) 21:12:33.33

>>185
> 何気なく使ってたけど調べてみたらC++用語だったか

どこの世界に非メンバ関数をフリー関数という馬鹿がいるのか詳しく
CかC++の規格のどこを参照すれば定義されているのか詳しく

**デフォルトの名無しさん** · 2021/11/27(土) 21:19:49.42

江添の馬鹿が言ってた。
https://cpplover.blogspot.com/2014/11/cunified-call-syntax-n4165-n4174.html

**デフォルトの名無しさん** · 2021/11/27(土) 21:31:03.67

Herb Sutterという馬鹿も使ってるな。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4165.pdf

**デフォルトの名無しさん** · 2021/11/27(土) 21:39:57.32

規格の上ではまだ見つけられないが
https://timsong-cpp.github.io/cppwp/n3337/over.match.oper#tab:over.rel.op.func
member function
non-member function
という当然の名称が出てきている
日本語版の規格分かる人「フリー関数」とやらを引用してくだしあ

**デフォルトの名無しさん** · 2021/11/27(土) 21:43:56.78

規格で定義された用語というより業界用語的なもんでないの
https://github.com/cpprefjp/site/issues/171

**デフォルトの名無しさん** · 2021/11/27(土) 21:44:30.32

馬鹿っていちいち言うなよ
素直になれや

**デフォルトの名無しさん** · 2021/11/27(土) 22:07:33.35

その「フリー関数」とはクラスのメンバー関数ではない非メンバー関数として
クラスのないRustではその非メンバー関数の定義はどうなるの？

例えば以下のprint_all()は適当に作ったトレイトPrintAllのメンバーかもしれないけど
現実には('a'..='z').print_all();が動作してしまうわけで『誰のメンバー関数』なの？それとも非メンバー関数？
trait PrintAll<T> {
　fn print_all(self);
}
impl<I: Iterator<Item=T>, T: Display> PrintAll<T> for I {
　fn print_all(self: I) {
　　self.for_each(|x| println!("{}", x));
　}
}