Rust part27 YouTube動画>1本 ->画像>1枚

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

公式ドキュメント
https://www.rust-lang.org/learn

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

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

※Rustを学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

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

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

前スレ
Rust part26
http://2chb.net/r/tech/1726838318/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
http://2chb.net/r/tech/1514107621/

乙巳

Rust The Book (日本語版)
https://doc.rust-jp.rs/book-ja/
Rust edition guide (日本語版)
https://doc.rust-jp.rs/edition-guide/
Rust by example (日本語版)
https://doc.rust-jp.rs/rust-by-example-ja/
Rust cookbook (日本語版)
https://uma0317.github.io/rust-cookbook-ja/
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/
Rust nomicon book (日本語版)
https://doc.rust-jp.rs/rust-nomicon-ja/
Rust async book (日本語版)
https://async-book-ja.netlify.app/
Rust WASM book (日本語版)
https://moshg.github.io/rustwasm-book-ja/
Rust embeded book (日本語版)
https://tomoyuki-nakabayashi.github.io/book/
Rust enbeded discovery (日本語版)
https://tomoyuki-nakabayashi.github.io/discovery/
Rust Design Patterns (日本語版)
https://qiita.com/Yappii_111/items/4ccc3a8461cdd4035651
https://qiita.com/Yappii_111/items/654717e6a6a980722189
Rust API guideline (日本語版)
https://sinkuu.github.io/api-guidelines/

Rust Reference Book
https://doc.rust-lang.org/reference/
Rust Standard Library
https://doc.rust-lang.org/std/
Rust rustc Book
https://doc.rust-lang.org/rustc/
Rust rustdoc Book
https://doc.rust-lang.org/rustdoc/
Rust rustup Book
https://rust-lang.github.io/rustup/
Rust Cargo Book
https://doc.rust-lang.org/cargo/
Rust unstable Book
https://doc.rust-lang.org/nightly/unstable-book/
Rust macro Book
https://danielkeep.github.io/tlborm/book/
Rust CLI (Command Line Interface) apps Book
https://rust-cli.github.io/book/
Rust Future Book
https://cfsamson.github.io/books-futures-explained/
Rust async-std Book
https://book.async.rs/
Rust tokio Book
https://tokio.rs/tokio/tutorial
Rust serde Book
https://serde.rs/
Rust Performance Book
https://nnethercote.github.io/perf-book/

>>3
何年も更新されてない上に誤訳だらけの非公式翻訳を貼り続けるのいい加減やめろ

前スレの「変数束縛」とか含めて非公式翻訳が勘違い野郎を生む諸悪の根源

スタバのマルチスレッドって効率悪いよね

はいはい、説教おじさんはほっといて気楽に質問してね～。勘違いでもなんでもok。サンプル欲しければコード書きますよ～。

日頃GC付き言語で開発しているからメモリリークがどういったプログラムで起こるのかあんまり実感できない
C言語で書かれたプログラムでメモリリークしやすいプログラムってどんなもんなの？

>>8
最近のPCはメモリたくさん積んでるから、リークしても気にしなくていいよ

メモリプレッシャーがかかっても不必要にメモリをつかみ続けるFirefoxのようなお行儀の悪いプログラムか増えてるからメモリが潤沢にあってもリークは気にしたほうがいい

使い捨てプログラムや低品質でもいいプログラムなら気にしなくてもいいけどそういうのはGC言語でやる

>>8
仕事の製品開発ならgc言語でもメモリプロファイラ一使えよ
ハードの性能向上を無駄に消費するクソソフト多すぎだろ

GC 付きでもメモリリークのようなことが起こることはある。
多くの場合に表面化しないだけ。
プロセスが終わるときにはどうせまるごと回収されるからガッと処理してすぐ終わるようなプログラムでは特に表面化しにくい。
見えにくいからこそ意識的に調査すべきで、 >>11 の意見に同意する。

逆に問題が表面化しやすいのは長期的に起動しっぱなしなもので、わかりやすい例ではウェブサーバ (またはその後ろでサービスを提供するプログラム) などが挙げられる。
ウェブサーバの H2O はそれを防止するのと高速化のためにセッションごとにメモリの塊を確保してその塊の頭から順番に使っていき、セッションが終わると塊をまるごと解放するというメモリ戦略を取ってる。

C言語でリークという話なのでこんな感じ。


// メモリリーク例1: mallocした後にfreeし忘れる関数
void leak_in_function() {
char* ptr = (char*)malloc(100);
strcpy(ptr, "Hello");
// freeがないのでメモリリーク
}

// メモリリーク例2: 条件分岐でfreeを飛ばしてしまう
void conditional_leak(int value) {
int* numbers = (int*)malloc(sizeof(int) * 100);
if (value < 0) {
return; // ここでreturnするとfreeされない
}
// 処理
free(numbers);
}

// メモリリーク例3: ポインタの上書きによるリーク
void pointer_overwrite() {
char* ptr1 = (char*)malloc(50);
ptr1 = (char*)malloc(100); // 最初のメモリブロックへの参照が失われる
free(ptr1); // 2番目のメモリブロックだけがfreeされる
}

// メモリリーク例4: 動的配列の不完全な解放
typedef struct {
char* name;
int age;
} Person;

void struct_array_leak() {
Person* people = (Person*)malloc(3 * sizeof(Person));

for (int i = 0; i < 3; i++) {
people[i].name = (char*)malloc(50);
strcpy(people[i].name, "John Doe");
}

free(people); // name用のメモリがリークする
}

こういうパターンが多いかな。
C++だと生ポインタ使わなくなるので大分解消されるけど。

バグが0になるまで投資を続けるのは誰もやらないのに
メモリリークを0にしようって言われたら投資してしまうのが人情というものだ

>>8
ここはRustスレなのに
なぜRustについて全く触れずにC言語の質問をするの？
C言語のスレがあるのだからそちらでしなさい

Rustについて触れずに他の言語の話だけをしている人たちも同罪
必ずRustについても言及しなさい

Rustのメモリ安全性の目的はメモリリークの回避じゃなくてダングリング参照の回避定期
ついでに競合アクセスも防ぐ

今度は「競合アクセス」と来たか

C言語はfree()しても断片化という問題が発生すると聞いたことがある
断片化してもOSが落ちたりはしないんだろうけど遅くなるとかならないとか・・・

>>19
断片化によって起こるのはメモリ効率の悪さ。
空いてるメモリの総量が充分にあっても必要分だけ連続したメモリがない(メモリ確保に失敗する)ということが起こる。
C では確保したメモリの場所が変わる(アドレスが変わる)ということは起すわけにいかないので断片化はそれなりに深刻な問題になりうる。
GC には copying gc のように不要メモリの回収と同時に再配置するものもある。

64bitのアドレスが枯渇したとして・・・全オブジェクトに印をつけるGCを使うか？

Rustは長時間動かすとメモリが断片化するから、サーバープログラミングに向いてない

https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
CDN世界トップシェアのCloudflareは、同社のグローバルなCDNの基盤として長らく利用してきたC製のNGINXに代えて、
Rust製のHTTPプロキシサーバである「Pingora」を開発して利用していることを明らかにしました。

Pingoraはすでに同社のCDNに採用され、毎日1兆回以上のリクエストを処理し、性能向上や数多くの新機能の提供を実現しており、
従来のNGINXと比較してCPUとメモリリソースの消費はいずれも3分の1程度に収まっているとのこと。

今時の標準アロケーターはよほどでかい領域を確保しない限りメモリの断片化は起きないようになってる。それでも問題ならカスタムアロケーター書くよ。

アマゾンのAWSもRust製
Webサーバサイドでリソース節約したいならRust一択

>>10
現代的には使われていないメモリがあるほうが「無駄がある」と考える思想なので、メモリはあればあるだけ使う(キャッシュやプリロードなど投機的な処理で体感的な速度を上げる)設計になってる。
本当に足りなくなるまでは掴んだままのほうが良いと判断してやってる。
現代のニーズに合わせた意図的な設計としてやってるのでリークとは違う。
良いか悪いかは知らんがリークとは違う。

Rustはいつメモリのコンパクションできるようになるの？

いつも渋滞している道路は無駄がない道路か
まあ徒歩より遅いなら燃料いらないからな

>>13
具体的で勉強になったわ

>>26
メモリ足りなくなったから不要なメモリ掴んでたら解放してくれと
OSからのメッセージが出ても掴み続けてるアプリが結構あるので
メモリが潤沢にあるからといってリークは気にしなくてもいいなんていう心構えでプログラミングしたらダメだぞという話

難しい話じゃないと思うんだけど1回で伝わらないのは悲しい

サーバでもアプリでもその他でも
プログラム起動中ずっと必要になるデータは
leak()して&'staticにしてしまっても構わない
これはメモリリークではない
一方ですぐ不要となるデータはleak()してはいけない
これはメモリ使用量が増えていってメモリリークになる
この違いをきちんと認識した上でleak()を活用しよう
ずっと必要になるデータを&'staticにできる大きなメリットがある

FireFoxのメモリリークは本当に酷い
Rust使ってるっていうのは嘘だろ

>>32
そこはC++コード
FireFoxでRustを使っているのはHTML/CSSレンダリング部分
メモリ管理部分を含めてメインはC++で記述されている
ソースが公開されているので誰でも確認できる

>>13
さすがにレベル低すぎだろ

リークしてるんじゃなくて意図的に解放してないだけ

本当にやばくなったら解放されるようになってる

メモリ食いが嫌ならAuto Tab Discardアドオンを入れろ

>>31
それを普及させて何がやりたいのか分からなかった
が「やりたいことと合致しない現実」を報道する自由を欲しているらしいと最近分かった

もし仮に特定のアプリに問題があったとしても
それはC++やRustの言語の問題ではない
このスレで特定のアプリの問題の話を始める人は愚か

>>33
何でいつまでたってもRustで書き直さないんだろな

>>30
主旨に反論したわけじゃない。 Firefox が例として不適当と言ってる。
Firefox は貪欲にメモリを使うが本当に足りなくなる手前で抑制的なモードに切り替わる。
Windows からメモリ不足のメッセージを出したときに Firefox がメモリを掴んだままなのは手放せるものは既に手放してるからだ。
メモリ不足になったときは本当にメモリ不足なんだよ。

FirefoxもChromeもその他のブラウザもやっていないが
究極的にはアクティブウィンドウのアクティブタブ以外の全ての使用メモリを原理的には解放できる
どの方針を採るにしてもC++やRustといった使用言語の問題ではなくどの言語でも可能だ
明らかにスレ違いの話題だから他のスレでやってくれ

tab閉じてもそのtabが使ってたメモリ解放しないんじゃリークだろ

>>40
長く表示していないタブを一旦解放する仕組みが導入されたこともあるんだが思ったより問題が大きくて消極的になった。
コンテキストの管理とレンダラは不可分な部分もあるので再レンダリングに必要な情報を残しつつ他は解放するってのは手間がかかって割に合わないと考えられてる。

>>41
閉じた時じゃなくてアクティブタブじゃなくなったときの話を >>40 はしてるのにそれがわからないなら黙ってろ。

モダンなブラウザはプロセスを分離しまくっていてプロセス間通信で協調する仕組みになってる。
タブひとつ (または数個のグループ) に対応するプロセスがあって適当な条件でプロセスごと消えて作り直されたりするので仮にメモリ管理に多少の問題があっても全体の堅牢さは維持される。

>>39
>Firefox がメモリを掴んだままなのは手放せるものは既に手放してるからだ。
これは嘘
単にお行儀が悪いだけ

>>40
>FirefoxもChromeもその他のブラウザもやっていないが
Safariは閉じたタブのメモリはもちろんのこと
長く非アクティブなタブのメモリは割と積極的に解放してる

いずれにしても各アプリのレベルのメモリ管理の話であってプログラミング言語と関係がない
しかもFirefoxのメモリ管理部分はC++で記述されている
ここRustスレで無関係な話をいつまで続ける気だ

>>39
>主旨に反論したわけじゃない
いやいや主旨を理解してないのに主旨に反論してるもしてないもあるかいな

Firefoxで失敗してるRustw

ふむ、広告ブロックを強化すればメモリ節約できるのでは

循環参照が起きやすい場面の一つだし、これこそプログラミング言語の仕様と関係のある場面じゃないのかな

>>48
C++が悪いということ？

Webページ毎に別なので
アリーナ的管理により循環参照があろうと一気に解放するためリークが起きようがない

メモリリークと脆弱性の混合物なら急を要するが完全に分離されたから意識低くなった

>>48
悪いっていうより、自由が利きやすいんじゃない

iterator traitのnextでiteratorの中のデータの参照を返すことがどうしてもできません
教えてください

>>53
コードで出して。

>>53
lending iteratorでググるといい

// まず、データを保持する構造体を定義
struct DataHolder {
items: Vec<String>,
}

// イテレータ構造体を定義
// ライフタイムパラメータ 'a を使って、参照の寿命を明示
struct DataIterator<'a> {
data: &'a DataHolder, // データへの参照
index: usize, // 現在の位置
}

// DataHolderにイテレータを作成するメソッドを実装
impl DataHolder {
fn new() -> Self {
DataHolder {
items: vec![String::from("one"), String::from("two"), String::from("three")],
}
}

// イテレータを返すメソッド
fn iter(&self) -> DataIterator {
DataIterator {
data: self,
index: 0,
}
}
}

// Iteratorトレイトの実装
impl<'a> Iterator for DataIterator<'a> {
// 返り値の型を&'a Stringと指定
type Item = &'a String;

fn next(&mut self) -> Option<Self::Item> {
if self.index < self.data.items.len() {
let item = &self.data.items[self.index];
self.index += 1;
Some(item)
} else {
None
}
}
}

// 使用例
fn main() {
let holder = DataHolder::new();

// イテレータを使用
for item in holder.iter() {
println!("{}", item);
}
}

やりたいことはこんな感じ？

こんな感じです
struct It<'a>{
i: &'a mut i32
}

impl<'a> Iterator for It<'a>{
type Item= &'a i32;
fn next(&mut self)->Option<Self::Item>{
Some(self.i)
}
}

mut いらん

iter()が作りたいのか、iter_mut()が欲しいのかどっちかな？
あとこれだと無限に続くイテレータになるけど終了条件は？

struct It<'a>{
i: &'a mut i32
}

impl<'a> Iterator for It<'a>{
type Item= &'a i32;
fn next(&mut self)->Option<Self::Item>{
self.i+=1;
Some(self.i)
}
}
こんな感じなのでmutはいります
本当はiter_mutが作りたいけれど難しそうなので
iterを作ろうとしたけれどどうしても出来ません
初心者です教えてください

すいません*つけわすれました

>>60
終了条件は２５です

結局毎回同じ参照返すならイテレータじゃなくてよくね

自分の可変参照を返したいならGATでこうする
use lending_iterator::prelude::*;

fn main() {
let mut v: Vec<String> = ["a", "b", "c", "d", "e"].into_iter().map(str::to_string).collect();
my_iter_mut(&mut v)
.skip(1)
.take(3)
.for_each(|s| s.push('x'));
assert_eq!(v, ["a", "bx", "cx", "dx", "e"]);
}

fn my_iter_mut<'a, T>(slice: &'a mut [T]) -> MyIterMut<'a, T> {
MyIterMut { slice, index: 0 }
}
struct MyIterMut<'a, T> {
slice: &'a mut [T],
index: usize,
}

#[gat]
impl<'a, T> LendingIterator for MyIterMut<'a, T> {
type Item<'next> where Self : 'next = &'next mut T;
fn next(self: &'_ mut MyIterMut<'a, T>) -> Option<Item<'_, Self>> {
if self.index < self.slice.len() {
self.index += 1;
Some(&mut self.slice[self.index - 1])
} else {
None
}
}
}

>>65
自己レス
即興で作って冗長な表記があったため
next()関数はこれで

fn next(&mut self) -> Option<Item<'_, Self>> {
(self.index < self.slice.len()).then(|| {
let nth = &mut self.slice[self.index];
self.index += 1;
nth
})
}

>>61
next()で返された不変参照r1（&i32）が生きてる間に次のnext()が呼ばれたら
r1の参照先の値が変わることになるからこの形はIteratorだと実現できないな
同じ値に対する&Tと&mut Tが共存できないルールに引っかかる

next()の戻り値にIt自体のライフタイム（&'b mut selfの'b）を含めて
戻り値の参照が存在してる間は次のnext()を呼べない形にしないといけないけど
Iteratorはそういう制限を想定してない

Vecなどを作れて逆順にもできるイテレータとは性質が異なる
異なるものを、どっちも同じだと頑なに主張し続ける必要はない気がする

67は一般的なイテレータの概念じゃなくstd::iter::Iteratorの話
このtraitを実装すると例えばIterator::max()も自動的に使えるようになるけど
この実装はSelf::Itemの暫定の最大値を保持しながら次のnextを呼ぶ必要がある
前の値を解放しないと次のnextを使えない状態だと
std::iter::Iteratorが使用者側に保証してる条件を満たせないし
安全なコードの範囲でimpl Iteratorのコンパイルも通せない

自前のIteratorトレイトを用意してもいいけど
それだとstd::iter::Iteratorが要求される処理には使えなくなる

>>68
Vecを作れるのも逆順も全て別の話
それぞれ別の要件を備えていないと一般的なイテレータではどちらも不可能
例えばイテレータ「1..」はVecを作れない＆逆順に呼ぶのも無理
std::iter::repeat(1)はVecを作れないがDoubleEndedIteratorを実装しているのでメソッドrev()が使えて逆順に呼べる！
自己可変参照を返す>>65のMyIterMutはスライス&mut [T]を内部に持っているため逆順呼び出しrev()メソッドの実装が可能

>>69
そのmax()は自動的に全てのイテレータに使えるわけではない
Self::Itemがstd::cmp::Ordを実装している時のみ使える
前の値を保持したままにできるか否かの性質についてもmarker traitを用意することで同じ枠組みに組み込めた可能性がある
それを出来ていないのがstd::iter::Iteratorの欠陥なので他を併用するのがRustでは当たり前になっている

イテレータの前の値を保持できるか否かのどちらが優れているかといえば
より効率的な機能を提供できる点で「前の値を保持できない」方が優れた機能を提供できる
例えばstd::io::BufReadのlines()を考えてみよう
毎回新たなStringを返してくるので前の値を保持できる仕様となっている
しかしlines()の利用で前の値なんて不要なことも多いからその観点からは無駄な仕様ともいえる
一方で「前の値を保持できない」性質にも対応出来ていたとしたら同じStringを使い回すことが出来て明らかに効率が良い
このような例は多数あり自己参照返しイテレータが別途必要とされて使われている理由である

>>70
長さが有限でも実行時にメモリが足りなければVecもreverseもないけど
「実行時に」という要件は備えなくて良いというルールがあるんだよね？

61（初心者）が実現できないimpl Iteratorで詰まってるんだから
できない理由を分かってもらうのが優先でしょ
イテレータの優劣とか代替案はその後でいい

>>73
rev()メソッドのtrait DoubleEndedIteratorはゼロコスト抽象化
逆順に並べ替えることはしないのでそのためのメモリは必要ない
既にある任意の構造を後ろからたどる、あるいは、後ろから計算するだけ

>>74
それならば別の条件が必要となるIterator::max()を事例に出すのはよろしくないかな
説明するためには単純にこれだけでいいよ
let first = iter.next();
let second = iter.next();
println!("{first:?} {second:?}");

>>76
next２回呼ぶだけだとstd::iter::Iteratorと関係なくなるだろ
自分がそういう使い方をしなければ問題ないってなるだけ

maxはstd::iter::Iteratorの実装に求められる条件の分かりやすい例として挙げた
別の条件まで気にするならmax_byでもいいけどそれはそれで初心者には余計なノイズが増える

コピーもcloneもできないデータの存在自体がノイズだね
本当はcloneできるんだけどゼロコストではできないとか言ってるのもノイズだ

結局>>53は何がしたかったのか

>>67
stdのIterator::nextの&mut selfのライフタイムはnextメソッドを抜けるところまで
(次のnextが呼ばれるまで生きてない)

つまりstdのIteratorでは&mut selfのライフタイムに依存するような参照を返すことはできないということ
そういう参照を返したいならlending iterator
逆に言えば&mut selfのライフタイムに依存しない参照であればstdのIteratorでも返せるということ

>>77
max_byも同じ
Ord実装型そのものかOrd実装型に変換してOrd::cmp()できる時のみ利用できる
それらを持ち出さなくてもSelf::Itemの条件なくcollect()すなわち収納型へのFromIteratorが適用される
つまりfirst要素とsecond要素が同時に存在することになると矛盾の説明で十分となる
そのため自己参照を返すイテレータはstd::iter::Iteratorがカバーする範囲になく別途必要となる話をしてきた

>>78
イテレータが返すのはデータ値自体とは限らず参照も返す
特に今回の質問者が返したい可変参照は明確に!Cloneが定義されていてもちろん!Copyでもある
それでも可変参照をイテレータが返すことができてVecへ収容することも可能なのはCloneもコピーも行われないためだ
さらにそれらと全く独立した話としてイテレータ自体への参照/可変参照を返す場合はstd::iter::Iteratorで扱えないためLendingIteratorを使うという話が本題

そんなに移動がしたいならこれでいい

first = into_next(iter); // iterはもう値を所有しない
second = into_next(first) // firstはもう値を所有しない

>>83
それによって新たにできるようになることや新たに生じるメリットは何？

C++でもRustでも変わらないメリットはcloneとdropをしなくてすむことだが

そういえば、Rust固有のメリットは'aが出てこないことと
'staticも出てこないことだな

全然話変わるんだけどPinky Crush新曲のlowercase lifetimeってRust関係あるのかな

>>61
mutでないiterも出来なくて困ってるとのことなので
スライスのiter()と同じものがLendingIteratorを使わずに書けるよ

struct MyIter<'a, T>(&'a [T]);

fn my_iter<'a, T>(slice: &'a [T]) -> MyIter<'a, T> {
MyIter(slice)
}

impl<'a, T> std::iter::Iterator for MyIter<'a, T> {
type Item = &'a T;
fn next(&mut self) -> Option<Self::Item> {
if let [first, rest @ ..] = self.0 {
self.0 = rest;
Some(first)
} else {
None
}
}
}

fn main() {
let a = ["foo", "bar"];
let mut iter = my_iter(&a);
assert_eq!(iter.next(), Some(&"foo"));
assert_eq!(iter.next(), Some(&"bar"));
assert_eq!(iter.next(), None);
}

組み込みFW屋さんなんだけどRustやってみようかな…
組み込み屋視点でRustはC++の何を解決してると思う？
組み込み屋なんて古いシステムばかりだからすぐに取って代わることは無いとは思うけど
年々複雑な製品を求められるから選択肢としては持っておきたい

zulip行けば？
ここにはカスしかおらん

>>88
ダングリング参照を発見出来るだけ……とは言えそれが重要ではあるのだけど。
C++ は結局は人が気を付けなきゃならないことだらけで、複雑になると手におえない。
知ってることでも複雑に絡み合った状況では間違う。
C++ よりは機械的に検証可能な範囲を広げてるだけでもありがたいものだよ。

>>90
え？マジ？
俄然興味湧いてきた
さっさと定時で帰って環境整えるか

ビット幅気にするようなケースだと
数値型の暗黙の型変換がないとか演算時のオーバーフローの扱いを明示的に書けるとかが結構ありがたい

科学 ＋ 5ch

【AI】AIはわずか2時間の対話で人間の性格をコピーできる [すらいむ★]
http://2chb.net/r/scienceplus/1733576027/

コメントに面白いことが書かれている

>>92
たしかに基礎的なことではあるがC/C++ではうっかり数値型の自動キャストでハマることもあるし
何よりも未定義動作が多くてこれも沼にハマる原因だな
それらを無くしたRustは賢明だ

釣れますか？

struct RefMutex<'a, T>(&'a Mutex<T>);
impl<'a, T> Iterator for RefMutex<'a, T> {
type Item = std::sync::MutexGuard<'a, T>;
//略
}

try_lockが失敗したらループが止まります
マルチスレッドならランダムに止まります 知らんけど

FnMut() -> Option<T>っぽいあらゆる処理を全部Iterator化しようという気概を感じるな

近寄らんとこ

イテレータが勝手にループすることはない
ループするよう別途コードを書かなければならない
Option<T>を返す関数をfとすると
while let Some(x) = f() { ... } で十分である
つまりイテレータ実装する意味がない
イテレータメソッドに繋げたい！という反論もあろう
それなら std::iter::from_fn(f) で十分である

Iteratorの話は、lifetimeの棍棒で殴られたという文脈で出てきただけだな

構造体のメンバーが&'a Mutex<T>なら
reborrowではなくmoveで取得した値に対しderef_mutが使える
moveなら殴られない

>>88
c++使ってる組み込みって組み込みLinuxとかじゃねーの？
あんまり組み込み特有の制限ないだろ
好きに組めや

これはポリシーというか戦略が違ってて、「今より少しでも改善するなら採用」だからじゃないかと
従来型の「最低限のクオリティに達するまではreject」へのアンチテーゼでもあるから
そして(文句あるかもしれんが)crates開発者は元々のエンジニアの質がそこそこ高かったからそれでも何とかなったものの、
同じ事をGitでやったからあの「ぼくがおもいついたすごいcrates」の山になったのだと思う
交通整理すらやる気無かったわけだ

とはいえ、「使われなくなったcratesは、いつしか動かなくなった事すら認識されなくなり、死んでいく」という、
Gitコマンド内でのライフゲームをやるつもりなら、ありなんだろうさ

C/C++からRustへ：Googleが示すファームウェア進化の道筋
https://xenospectrum.com/google-revamps-firmware-with-rust/

読み終わった

>>102
具体的なアプローチは以下の通りである：
(1) 段階的なRust導入：
　略
(2) 既存のCコードベースとの統合：
　略
(3) ベアメタル環境への対応：
　略
(4) ビルド最適化とパフォーマンスの考慮：
　略

Rustで連番IDを発行する関数はこれでいい？

fn new_id() -> Option<usize> {
thread_local! {
static ID: Cell<usize> = Cell::new(0);
}
ID.get().checked_add(1).inspect(|&new_id| ID.set(new_id))
}

mutableなRange（0..）をIteratorとして使う小技があるけど
オーバーフローは意識したことないな

fn new_id() -> Option<usize> {
use std::cell::RefCell;
use std::ops::RangeInclusive;

thread_local! {
static ID: RefCell<RangeInclusive<usize>> = RefCell::new(0..=usize::MAX);
}

ID.with_borrow_mut(|ids| ids.next())
}

>>105
Cellで済むところがRefCellになってしまってメリットがよくわからないです

合わせたつもりだったけど104の実装だと最初のidは1か

0から開始できる形でCellにこだわるなら↓みたいな実装もありそう

fn new_id() -> Option<usize> {
thread_local! {
static ID:Cell<Option<usize>> = Cell::new(Some(1)); // ←0開始ならSome(0)
}
ID.replace(ID.get().map(|i| i.checked_add(1)).flatten())
}

スレッド単位の連番て何やの？

>>104をマルチスレッド対応するなら
まず初心者入門向け版としてはCellをMutexに変更で動く

fn new_id() -> Option<usize> {
static ID: Mutex<usize> = Mutex::new(0);

let mut id = ID.lock().unwrap();
id.checked_add(1).inspect(|&new_id| *id = new_id)
}

inspectの間違った使い方

正しいようだが何を問題視してる？
ちなみにRustではmatch(またはif let)で書いた時に
次のようなパターンになる場合に
わかりやすく短くメソッドにして繋げることができる

and_then(f)
　| Some(x) => f(x),
　| None => None,

map(f)
　| Some(x) => Some(f(x)),
　| None => None,

inspect(f)
　| Some(x) => { f(x); Some(x) }
　| None => None,

or_else(f)
　| Some(x) => Some(x),
　| None => f(),

unwrap_or_else(f)
　| Some(x) => x,
　| None => f(),

ok_or_else(f)
　| Some(x) => Ok(x),
　| None => Err(f()),

など

全然判り易くないぞ
語彙に直交性が全く無い

語彙の問題もあるのかもしれないけどasyncの問題もあって中の人たち含めみんな昔ほどコンビネータで書かなくなった

Optionを自然に真偽値ベースで英語で読むと判り易くなっている
例えばunwrap_or_elseは
真ならunwrapすなわちSome(x)→x
orは前提が偽つまりNoneの場合がfの対象でNone→f()

似ているor_elseは
Some(x)→Some(x)となる部分だけ違うとすぐわかる

その逆は当然and_thenとなり
andは前提が真の場合がfの対象でSome(x)→f(x)となる

通常の動詞1つの時は真つまりSome(x)の時が対象で
mapは値を写像してSome(x)→Some(f(x))
inspectは値を変化させずに実行Some(x)→{ f(&x); Some(x) }
filterも値は変化させずに実行して偽なら捨ててNone
Some(x)→if f(&x) { Some(x) } else { None }

現状追認オジの意見ほど意味のないものはない

バカでも読めるコードが正解なんだよ

コボラーがそんな事言っていたなw

あほくさ。
そこらの医学でも物理でも法律でもいいが適当な論文が単語や言い回しだけ平易にすればバカでも読めるようになるか？
前提知識がないとどうせ意味なんかわからん。
プログラミングも同じ。
理屈が理解できるだけの能がなければ表現ばかり平易にしても無意味。

不必要に難解にする意味はないが、言い回しだけ過度に平易にする意味もない。

特定のプログラミング言語を使えることを物理医学レベルと思ってるのは思い上がり

>>120
どこをどう読んだらそんな風に読めるんだ？
言語は当然にそれで表現すべき何事かがある (書く人はそれを理解している) という話なんやが。

>>121
自分はバカだと自覚したほうがいいぞ
ソフトウェア開発するならな

>>122
それは大変によくわかる。
自分で書いたものすら意味わからんようになるのは普通のことだからな……。

だから意図を表現することが大事で、小さなロジックの断片にでも名前を付ける。
その状況を表すための名前 (専門用語) こそが大事。
訓練されていない人にとって平易であることとは違う。

>>116
現状追認主義なのに推奨されてる用量・用法は守らず動くだけのコードを披露したがるのは理解できないんだが

ママに褒めてもらいたい幼児の心理だよ
わかりやすいだろ

>>117
「ごっちゃに書いて見通しの悪いコードにはせずに、
高階関数のメソッドチェーンにして、
各々のメソッドで個別に関数またはクロージャで処理を指定する。」
ここまでは共通認識でいいんだよね？
万が一これにも反対の人がいるならばまずは代案を明示的に出してほしい

以上の共通認識の上で
語彙の問題という話が出ているからメソッド名の付け方に問題があるということなのか？
それともメソッドが多すぎる(機能が多すぎる)またはメソッドの分別の仕方に問題があるということなのか？
まさか高階関数がわかりにくいという話ではないと思うが

なんでもメソッドチェーンで繋げればいいわけでもなければ
なんでも分割して書けばいいわけでもない
ケースバイケース

一番ダメなのは慣習や暗黙の了解を無視したコード
>>104や>>110はその一番ダメなやつ

つかこんな基本的なことから説明させようとするなよ

>>127
んでお前ならどう書くんだ？
Rust使った新システムで慣習や暗黙の了解はまだない時に自分で考えてソース書くときはどうするんだ？

>>127
また自分勝手な慣習や思い込みの暗黙の了解かよ

vecs.iter().map(|x| x.iter()).flatten().filter(...)

みたいなのは書いてて気持ち良いけど、全員が賛同するわけではないよな
Rustの公式のドキュメントだって関数型スタイルの書き方と手続き型スタイルの書き方の両方を紹介してるわけだし
そういう「高度な書き方」をバッサリ切り捨ててるGO言語が人気というのもそう

>>127
具体的に何を問題視してるのかわからん
Mutexを使わずに効率よく実装できるケースのようにみえるが
初心者入門向けと書かれてるからMutex利用もアリだろう

>>130
そのコード自体はともかく
そういうメソッド連鎖は標準ライブラリや有名クレートのソースにいくらでも出てくるぜ
まずはソース読んでみな

>>132
自分も好みとしては関数スタイルを使うよ
だけど >>126 のような「それが正しい形であり、みんなそちらを使うべき」みたいな言説はあほらしい
有名どころのOSSのコントリビューターだって、利用者からの質問への回答やチュートリアルでは 「for文で一つずつ要素を Vec に push_back で詰める」コードを示すことも実際にある

Rust開発者は関数スタイルを好む人も多いと思うけど、それは好みの域を出ないと思う

まあ存在する以上はユースケースがあるってことだからな。

コードゴルファーのために存在してるわけじゃないからな

そろそろitertoolsを標準ライブラリ化する話はないのか？

個別に取り入れられてる
まとめて標準化はない
棲み分け

>>127
そのマルチスレッド対応コードに
指摘の「慣習や暗黙の了解を無視したコード」とやらが見当たらないのだが
そもそも慣習や暗黙の了解とはどういう意味で使ってる？

>> マルチスレッド対応するなら
>> まず初心者入門向け版としてはCellをMutexに変更で動く
>>
>> fn new_id() -> Option<usize> {
>> static ID: Mutex<usize> = Mutex::new(0);
>>
>> let mut id = ID.lock().unwrap();
>> id.checked_add(1).inspect(|&new_id| *id = new_id)
>> }

こういう C のコードを Rust で描く場合どうやればいい？


もちろん unsafe 利用 ok として

型のキャストは
std::mem::transmute

assert_eq!((3.14_f32).to_bits(), 0b1000000010010001111010111000011_u32);
assert_eq!(f32::from_bits(0b1000000010010001111010111000011_u32), 3.14_f32);

JAIST、「並行量子通信プロトコル」の完全な自動形式検証を実現
http://news.mynavi.jp/techplus/article/20241220-3090485/

>>138
中級者向けにはこれでええんかね

fn new_id() -> Option<usize> {
static ID: AtomicUsize = AtomicUsize::new(0);

let mut old_id = ID.load(Relaxed);
while let Some(new_id) = old_id.checked_add(1) {
match ID.compare_exchange_weak(old_id, new_id, Relaxed, Relaxed) {
Ok(_) => return Some(new_id),
Err(updated_old_id) => old_id = updated_old_id,
}
}
None
}

Rustに興味出てきたからとりあえず、とほほさんのサイトに目を通してみたんだけど
…もしかしてあの方、非同期処理と並列処理をごっちゃに理解している？

https://www.tohoho-web.com/ex/rust.html#async-await

>>143
lock freeはそう
今回のアルゴリズムはRelaxedでも大丈夫だがmemory orderingに注意を要する

>>144
executor (runtime) とそこでの使い方次第
single thread で並列(parallel)なく並行(concurrent)のみも可能であるし
それをmulti threadで並行並列も可能であるし
blockさせて並行なく専属並列も可能

Rustしか勝たん

こういうアホが湧いてきたときがピークだな

WebAssemblyはRustが主流なイメージだけど実際どんなもんだろ

linuxカーネルがシェルスクリプトの付属品にならなかったのはシェルを変更できるから
だがjsは、変更不可能にすればjsが永久に主流だというのを意図的にやっている

>>149
何いってんだお前？

触るな触るな

ひといないねこのすれ

だからマルチスレッドで発生しうる競合はその2つだけじゃないから

それだけで安全と言い切れるわけないだろ

そもそも安全性ってお前が作るアプリで必要なの？
Linuxカーネルや組み込みだったらわかるけどそんな高度なプログラム作ってんの？
飛行機のシステム作ってて命がかかってるとかならわかるが、その辺のアプリで安全性とかどうでもいいよね

Rust馬鹿信者は開発生産性を軽視しすぎだ、開発生産性を犠牲に安全性に振ってるのがRustだがアプリの特性によって安全性なんぞどうでもいいことが多い

開発生産性が一番重要

難しさによる障壁はあるけど、慣れれば生産性自体は高い言語だと思う
ライブラリ多いし、ちょっとしたツールを作る程度ならエラーハンドリングもそんなに頑張らなくて良いし (anyhow を使えば割と雑に書ける)

流石にPythonのような手軽さは無いけど、C++よりは遥かに書きやすいし、個人的にはC#やJavaよりも楽だと思うくらい
これは言語仕様でなくツールの話だけど、プロジェクトを作ったり、ライブラリを追加したりするのが楽

学習コストが高いのはその通りで、誰かが書いたツールを他の人が保守しづらいみたいな問題はどうしようもないけど…
(そういう用途ならGoが良さそう)

>>154
他人が書いたコードの保守しやすさはGoより上だと感じてるけどな
型含めてコード上に情報が豊富で作者の意図を取りやすいから
かなり巨大なOSSでも割と楽にプルリクとか出せる

>>155
「自分がRustに慣れてるなら」それは自分も同意
自分の意見は
・Rustは分かるようになるまでが大変
・理解できれば開発者にとって強力な言語
で、「Goの方が向く」というのはとっつきやすさを含めた話のつもりで書いた
他言語の経験者から見たら、たぶんRustは型やトレイトの意味を理解するのが難しいし、参照などのルールを理解しないとコンパイルすら通らないから、Goの方が触りやすいんじゃないかと思う

Arc, Rc, Cell, Mutex とかの型は分かる人にとってはmeaningfulだけど、初学者がすぐに分かるものではないと思う

>>156
単純にメンテする人員を確保しづらいという意味ならそれはそう

rustのいい所はresultやoption.その他色々な型について文脈が大体決まっていること。なので慣れると人が書いたコードでも読みやすい。c#やjavaとの比較であれば開発効率は大体同じか、勝っているぐらい。nullや例外がある言語はプログラムがどうしても汚くなる。
rustはaiにコード生成させた時の品質も割といい。コンパイルエラーでても対応方法が具体的なのでそのままメッセージをaiに渡すだけで直る。

AIが当たり前の時代においてはコードの記述量そのものは開発効率に直結するものではなくなる。どの言語でも似たような事は出来る。でも作られたコードが、正しいかどうかは別の問題。
AIはたまに嘘を付くので、それをコンパイラで厳密にチエックする必要がある。そういう意味では関数型言語へのシフトは進むし、rustはいい位置にいると思う。

関数型関係ないから

>>159
関数型である部分ではなく
Rustが安全性にも役立つ史上最強の型システムを構築したことが決め手かな
特にトレイトそしてトレイト境界
さらに例えばSendやSyncといった概念的なトレイトなど

そうなんだ、Rustってすごいんだね！

関数型関係ないから

お前ら9連休はちゃんと楽しめたか？

九連休に一回もコード書いてない陽キャはこのスレ書き込み禁止な

体力落ちないように散歩しまくってたら脚の裏に豆出来たよ

陰キャなのに今年のコード書いてなかった

fn main() {
println!("{}年", (0..10u64).map(|i| i.pow(3)).sum::<u64>());
println!("{}年", (0..10u64).sum::<u64>().pow(2));
}

sum()の型アノテーション外せないの？

>>167
型アノテーションは必要。
オーバーフローしない十分に大きな型を選定しなきゃならないから。
浮動小数点ならオーバーフローはしないが必要な精度を推論しようがないことにかわりない。

その論理は明らかにおかしい

0..10がu64なんだからsumの結果も当然u64だろうという気持ちにはなる

そこは指定必須
例えばu64の和をu128で求める型を以下のように増やせるから無指定を許すとコードが曖昧になる

struct MySum(u128);

impl std::iter::Sum<u64> for MySum {
fn sum<I: Iterator<Item = u64>>(iter: I) -> Self {
iter.fold(MySum(0), |sum, n| MySum(sum.0 + n as u128))
}
}

fn main() {
// u64の和をu128で計算できる
let x = [u64::MAX, u64::MAX].into_iter().sum::<MySum>().0;
assert_eq!(x, u64::MAX as u128 * 2);

// このコードはデバッグモード時にoverflowして悪手
let x = [u64::MAX, u64::MAX].into_iter().sum::<u64>();
assert_eq!(x, u64::MAX - 1);

// ラップアラウンドさせたいならこうする
use std::num::Wrapping;
let x = [u64::MAX, u64::MAX].into_iter().map(|n| Wrapping(n)).sum::<Wrapping<u64>>().0;
assert_eq!(x, u64::MAX - 1);
}

このように必ず型を指定して使い分けをする

Monoidを先に整備すればこんなことにはならずに済んだろうに

>>171
そういうのは本来sumの役割じゃなくないかという気持ち

オーバーフローとかは関係なくて型システムの制約と標準ライブラリの実装方法の問題だよ

sum()の戻り値の型をIterator::Itemに固定するとItemが参照型の場合に対応できないな

そら固定したらダメだよ

ジェネリクスで良いとは思うけど、デフォルトの型として元の型になってくれると便利な気はする
参照の場合とかは、数値型なら .copied() で値にできるし

>>177
copy可かつcopyでコスト増にならないのはプリミティブな数値型だけだよ
巨大な整数値やタプルや行列などもありうる
例えば std::simd::Simd のimpl Sumでも参照を扱ってるね
impl<'a, const N: usize> Sum<&'a Simd<u32, N>> for Simd<u32, N>

もうfoldでいい気がしてきた

fn main() {
use std::ops::Add;
println!("{}年", (0..10u64).map(|i| i.pow(3)).fold(0, u64::add));
println!("{}年", (0..10u64).fold(0, u64::add).pow(2));
}

３乗の総和＝総和の２乗の証明は今年の入試で狙われそうだな
帰納法使えば簡単だけどn(n+1)/2の導出からだとだるい

そのSimdのSum実装のこれを見てそこに落ち着いたのか
iter.fold(Simd::splat(0 as $type), Add::add)

Rust排除のためのMozilla潰しが始まったか？

GoogleとLinux FoundationがChromiumの開発と維持を支援する基金「Supporters of Chromium-Based Browsers」を設立、MetaやMicrosoftなども参加 - GIGAZINE
https://gigazine.net/news/20250110-supporters-of-chromium-based-browsers/

Chromium プロジェクトが Rust の利用をサポート
https://developers-jp.googleblog.com/2023/02/supporting-use-of-rust-in-chromium.html

Rust を導入する目的は、シンプルで（IPC を使わない）安全な（全般的に C++ よりも複雑でなく、サンドボックスでメモリの安全性に関するバグは発生しない）形で 2 の法則を満たすことにより、

Rust は、Mozilla がブラウザを書くために特別に開発したものなので、このテクノロジーが Chromium でようやく使われ始めるようになるのは、理にかなったことです。
システム ソフトウェア業界に莫大な貢献をしてくださっている Mozilla に感謝いたします。
Rust は、安全性とパフォーマンスの両方を言語に期待できることを見事に証明しています。

むむっ

そもそもMozillaはRust開発者の大半をリストラしてしまったし
すでに単なる1ユーザ企業に過ぎなくて、Rustの発展にはあんまり関係なくなってる
どちらかというとMDNを維持できるかとかの方が重要そう

GoogleはChromeが独占禁止法違反にならないようにFirefox支援しててMozillaは生きててもらわなきゃならん
デフォルトの検索エンジンに採用する見返りにGoogle社から受け取ってる金がMozillaの収益の90%を占めるから潰すのはその金を絞るだけでいい

>>187
おまえ日本語不自由なら無理に書き込まなくてもいいんだよ？

>>188
お前には難しかったか
すまんな

添削してあげる

GoogleのChromeが独占禁止法違反にならないように対抗馬のFirefoxにある程度台頭してもらう必要がある
そのためGoogleはMozillaを投資している
投資の一例としてMozillaはデフォルトの検索エンジンに採用する見返りにGoogleからMozillaの収益の90%を占める投資を受け取ってる
仮にGoogleがMozillaを潰すのならその投資を絞るだけでいい

訂正

誤 そのためGoogleはMozillaを投資している
正 そのためGoogleはMozillaに投資している

いずれも着実にRust化

>>190
俺より頭が良さそう
尻拭いしてもらってすまんな

ところがMozillaに資金援助してるのが
独禁法違反ともめてるわけだ

ChromeもMozillaも各々Rust化へ向かってるなら
今後はここでもう揉めなくて済むな

>>189
結局添削されてるな
ガイジ乙

>>188
あなたは頭が不自由なのですね判ります

Rust 1.84.0でprovenance関係が安定化されてるね

Rustで描かれてるMozillaがめっちゃ不安定なんすけど

>>199
Mozillaのメモリ管理や中核部分はC++で書かれている

＞2016/07/20 まとめ：Firefox 48 には、Rust で書かれたコードが初めて含まれます。以降のバージョンにも Rust での実装が予定されている部分があります。
10年掛けてまだ置き換わってないってどういう事なの

現場を動かすほどの言語じゃなかったってこと
いずれ忘れ去られていくだろうねｗ
必死で宣伝するやつはしばらく残るだろうけど

Rust化を進めようとしているのはChromeの方だよ
ソース >>182 >>184

>>201
単純に考えてその時点で約20年積み上がってからね

firefoxシェアほとんど無くなって自立収入ではやっていけなくて
独占禁止法を逃れるためのGoogleからの資金で開発やってるから
基本部分は変えずに独自機能の強化の方に力を入れてるんじゃないかな

GoogleはRustでXilemやってるね

WindowsのOsStringってなんでUTF-16直接保持しないであんな面倒なことやってるんだろ

>>207
Rustは時代に応じて文字列をUTF-8で扱っていてString型には必ず正規なUTF-8が入ることが保証される
しかし外の世界は魑魅魍魎でUnicodeですらないものを扱えないといけない
ファイル内容やネット通信でUTF-8以外が定められてるならencoding_rsを使って明示的に変換しながら読み書きする

>>207
一方で問題となるのはファイルシステムのパス等だ
OS環境毎に異なるプログラムは書きたくないからコード上はString型つまりUTF-8で統一して扱いたい
パスがUTF-8自体もしくはUTF-8に1対1で対応するUTF-16等ならプログラム中はString型(＝UTF-8)で扱えてうれしい
しかしパス内にはUTF-8に変換できないものも含まれている可能性があるためOsString型(＝UTF-8＋α)として区別して扱う

>>207
OsString型は以下の2つを満たす抽象的な型となっている
正規UTF-8のみを含むならばコスト無しでString型に変換できて逆にString型からは常にOsString型にコスト無しで変換できる
各OS環境で扱える全ての表現と1対1に対応できる(特に正規なUnicodeならばUTF-8に対応する)
この1対1が重要でありUnicodeでない場合も読み書きしての同一性が保証される
これらを満たせば内部の構造は自由でありユーザープログラムがその構造に依存することはなく構造を知る必要もない

>>207
Windows OSのUTF-16環境であってもユーザープログラムは環境の違いを気にせず統一して扱えるようにString(＝UTF-8)とOsString(＝UTF-8＋α)で扱う
そのため正規なUTF-16はUTF-8に変換して内部で扱うことになる
しかし実際には任意の16bit列がパス等に現れることも可能なのでUTF-16以外の場合も1対1にOsStringに変換できなければならない
この任意の16bit列にはUTF-16のみの場合も含まれるため区別してWTF-16と呼ぶ
つまりWTF-16＝UTF-16＋αの関係になっている
あとはそれと1対1に対応するWTF-8＝UTF-8＋αを上手く定義してやれば前述の性質を満たす内部構造が完成する
以上おわり

> Windows OSのUTF-16環境であってもユーザープログラムは環境の違いを気にせず統一して扱えるようにString(＝UTF-8)とOsString(＝UTF-8＋α)で扱う

OsStringの内部エンコーディングがWTF-16だと統一的に扱えないと言いたいの？

どうなっているか、ではなく、なぜそうなっているか

String <-> OSString <-> System Native String

右の変換コストよりも左の変換コストを下げることを優先してる
そのほうが標準ライブラリ内部で共通の実装や似通った実装を使いやすい

System Native Stringは直接取り扱わず、OsStringでラップして扱うのが原則なら
ゼロコスト抽象化の観点から言えば右の変換コストをゼロにするべきでは？
左の変換は必ず行うとは限らないのだから

というか、Windows以外なら実際右の変換が実行時チェック無しのゼロコストになってて、左の変換時にチェックしてるんだから、その説明には合わないじゃないか
どこにそんな説明が書いてあるんだ

>System Native Stringは直接取り扱わず、OsStringでラップして扱うのが原則なら
別にそんな原則ない
OsStringで楽できないなら使わなくてもいいよ

>ゼロコスト抽象化の観点から言えば右の変換コストをゼロにするべきでは？
それは君がマルチプラットフォーム対応のライブラリを維持管理する立場で考えず
Windows中心でしか物事を見てないからだよ

>というか、Windows以外なら実際右の変換が実行時チェック無しのゼロコストになってて、左の変換時にチェックしてるんだから
間違って理解してるね

>どこにそんな説明が書いてあるんだ
公式ドキュメント

？ ちょっと調べたらバレるくだらない嘘つくんだったらもう相手してあげないよ

外部と内部でデータの表現形式が異なる場合
外部に従属するソフトウェアを作ってるのでなければ
可能な限り境界に近いところで変換を行うのは当然の選択

外部とUTF-8変換する微々たるコストが深刻になる用途があるならば標準ライブラリを使わずに独自に実装すればよいだけの話
標準ライブラリはAsRef<OsStr>やAsRef<Path>でそのままstrやStringが使えるように設計されている
File::openなどでのパス指定の引数もこのAsRef<Path>がトレイト境界となっている
as_で扱える設計が望ましい

>>220
後半の話は全然関係ないじゃん

>>221
後半ためにはOsStringがStringを含む拡張になっていなければならない
そうなっていれば型の読み替えだけでas_refできる

>>222
それは>>213が書いてるようにどうなってるかの話で
なぜそうなってるかの理由ではないよね

File::openはAsRef<Path>を受け取るけど
windowsならすぐにVec<u16>に変換されてる

仮にwindows向けOsStrの内部がu16ベースで
File::openがInto<Path>を受け取る実装だったとしても
処理内容は変わらない

>>223
それは違うな
str.as_ref()と参照を読み替えるだけでOsStrになることが重要
そのためOsStrとstrのPartialEqも用意されていてコストなく比較可能
UTF-8のみであればOsStrとstrは一致することが本質

>>224
どれも結果であって原因ではないね

>str.as_ref()と参照を読み替えるだけでOsStrになることが重要
なんで重要なの？

>そのためOsStrとstrのPartialEqも用意されていてコストなく比較可能
OsStrとstrをコストなく比較可能にするために
System Native StringをOsStrにするタイミングでコストがかかってる
コストをかけるタイミングだけの違い
OsStrとstrがコストなく比較可能でなければならない必然性は全くない

ファイル操作なんてI/O負荷の方が高いんだからファイルパスの変換コスト気にする必要あるか？
文字コードが違う環境はwindows以外にも色々あるだろうし。

直交する話を持ち出しても元の議論には一切影響しませんが

一般的な話として
アスキー非互換かつサロゲートペア問題を抱えるUTF-16は欠陥品なので使用は好ましくない
UTF-16や16bitで扱うシステムはユニコードが16bit時代に決めた古いシステムがほとんどで稀に後に無知者が導入したものがある程度

Rustで文字charは正しく32bitとなっており
文字列strはネット上やファイル内でも推奨されアスキー上位互換のUTF-8になっている
さらにOsStrはそのUTF-8の上位互換となり集合的にはOsStr⊃str⊃アスキーとなっている
それさえ満たせば細かい内部実装は各OS毎に異なってよい
欠陥品のUTF-16は何も満たせずそこでも排除で正しい

また意味のない話を始める
さすが複オジ

OsStringの用途はファイルパスに限られたものではないけど主たる用途で性能が問題にならないというのは今の実装方法が選ばれた理由の一部ではある

UTF16はメモリとパフォーマンスのバランスが良い
オンメモリの内部形式としては悪くないチョイス

別に理由が無いなら無いと言えばいいのに、変にこじつけようとするから

スレを荒し続けているUTF16信者は何がしたいの？
本気でUTF16がいいと信じているならそういうcrateを作って布教すればいい
そんな需要はないと思うが

>>225
それは >>219 が述べるように「変換は境界で」という基本思想による。
このやり方が複雑さを避ける良い方法だというのは歴史の積み重ねで皆が実感してきたことなので今さらどうこう言っても「その話はもう終わった。蒸し返すな」という気持ちなんだよ。

じゃあせめて「その話」がどのissueでされたかでも貼ってくれないかな

甘え過ぎw

ソース無しの妄想だからそう返すしかないか

複オジはともかく質問者もまだ分かってなかったのか

わかった
少なくともこうして容易に使えることが最低必要条件
fn OsStr::to_str(&self) -> Option<&str>
したがってOsStrはstrを含む拡張集合
それ以外に制約はなく各OS毎に内部実装は自由

それがお前の妄想でないという根拠は？

impl AsRef<OsStr> for str

issueで内部が16ビットではそれが機能しないと

機能しないと議論されて決定してる

>>234
219と225は同一人物だぞ

>>232
特定のプラットフォームに依存するコードはなるべく減らしたいという動機は理解できるんだよね？

可能な限り境界に近いところで外部表現と内部表現の変換を行うことがプラットフォーム依存のコードを減らすことに寄与するというのもわかるよね？

あとは外部の表現形式を内部でも維持したとしてもデメリットを上回る十分なメリットがあるかどうか
OsString/OsStrの主たる用途ではそれだけのメリットはないという判断
メリットがある用途ならOsString/OsStr以外を使いましょうということ

str <-> OsStrの話は差異をうまく隠蔽しにくくシグニチャに影響しうるというのがあるけど仮に影響しなくても境界で変換するのが望ましいという判断は変わらなかったはず

https://github.com/rust-lang/rfcs/pull/575
https://github.com/rust-lang/rfcs/blob/master/text/0517-io-os-reform.md#string-handling

>>247
ありがとう、RFCのほう探せばよかったのか

> ## Wide string representation
> Downsides:
> * These conversions have inconsistent performance characteristics between platforms. (Need to allocate on Windows, but not on Unix.)

やっと納得できる理由が出てきた、これはたしかにな…いやでもなあ、直接OsString/OsStrを触るAPIがもっと充実していれば別にString/strとの変換をそこまで気にする必要もないのでは？
一気にString/str相当のAPIを実装するのも手間だし、OsString/OsStrで何かやりたかったらとりあえずString/strと変換してなんとかしてくれ、だからここではプラットフォームごとの差を付けたくない、って方針だったのかね？
とはいえ、考えられる発展としていろいろな文字列型を一般化する抽象化を作れるはずとかちゃんと書いてあるし、まあまあ納得できる経緯説明ではある
ありがとうね

> // and ultimately other functionality typically found on vectors,
> // but CRUCIALLY NOT as_bytes

…とか書いてるけど、今は普通にas_encoded_bytesとして実装しちゃってるし、結局なんだかよく分からんなあ

>>248
>> * These conversions have inconsistent performance characteristics between platforms
こう書かれてるけどパフォーマンスという点では特にDownsideじゃないと思うんだけどね
今の実装でも発生してるし違う環境用のOsStringを1つのプログラムが実行時に混ぜて扱うわけでもないし

問題なのは内部コードにアロケーションタイミングの違いみたいなのが侵食して分岐が増えること
わかりやすい例としてはOsStr::new(“foo”)が&OsStrを返せなくてCow<OsString, OsStr>になるとか

そうだね
だから現状の仕様で正しくて
10年間も問題視されていない
許容できない用途が仮にあるならWindows専用のクレートを作ればいい

as_encoded_bytesの話はこれ
https://github.com/rust-lang/libs-team/issues/306

> # Alternatives
> * A split_at(&self, pos: usize) -> (&OsStr, &OsStr) style method. This is ostensibly simpler than a slicing API. But:
> ** The OMG-WTF-8 encoding does not support this. It requires some splits to produce overlapping slices, so that left.len() + right.len() > orig.len(). The encoded bytes on one side of pos might form a valid OMG-WTF-8 string while those on the other side do not.
> *** RFC #2295 that proposes this encoding was merged five years ago (but has not been implemented).

何その絵に描いた餅を喉に詰まらせて死ぬみたいな話……

ほとんどのシステムはUTF-8以外のファイル名があったら無視かエラーでいいからどうでもええわ

http://2chb.net/r/tech/1691038333/514-528

ﾜｯﾁｮｲ付いてないとどこにでも出るな妖怪

LinuxカーネルのメンテナがRustコードを混ぜることを「癌」と呼び、開発者間の対立が激化中 - TechFeed
https://techfeed.io/entries/67a52d4677bdbc0f2990eed9

争え……もっと争え……

Linusが一喝するまで収めるの無理やろ

そりゃドライバーはカーネルのインターフェイスに従って動作すべきだから、ラッパーなりで隠蔽すべきなんじゃないんかね。

個別のドライバーのためにカーネル側をカスタマイズするのはインターフェイスを侵食する越権行為だから、そんなのドライバーのラッパー側でやれ、と言いたくなるのはわかる。

>>257
それは君の理解が間違っている

今回はRust製の各デバイスドライバが独自のCバインディングを持つ不便な状況を改善するためのパッチだ
つまりカーネルのC側に手を入れるパッチではなくC側は同じままで変更は一切ない
今回の件は該当部分dma_alloc_coherent()のC⇔Rustの抽象ラッパーのコードを含めるパッチだけだ
それさえメインテナーに拒否されたため大問題になっている

デバドラはRustで書くのが普通になってきているから
そういう共通ラッパーという形のRustインターフェイスが色々と欲しいのよね
でもそれはいずれカーネル自体のRust化へ繋がる道になるから強く反対してるのよ

普通に考えたら異種の言語が混ざるとデバッグと開発の障害でしかないからどこかで境目は必要

>>258
メンテナーがRust用コードのメンテナンスを拒否したということじゃないの？
Rust for Linuxでサポートするような話じゃないんかね。

>>260
異種の言語を混ぜる話なんか誰もしていない
今回の事件のパッチも異種の言語を混ぜることなくCのAPIはそのままで
その上にRustの層を作る話

In response, Krummrich explained the Rust for Linux effort is creating Rust code that abstracts the C APIs for all Rust drivers and is maintained by Rust devs. In other words, the C side of the kernel stays the same, and Rust drivers use abstractions to that C code, and that these abstractions are maintained by a team centrally in rust/kernel, all of which is arguably better than drivers having their own individual C bindings.

最終的にRust側のメンテナが切れてSNSで晒したりしたのは良くなかったけど
技術的にはC側に迷惑かからないように十分配慮して、出てきた懸念も全て潰したにも関わらず
「とにかくRustに関わりたくないから却下」だったからまぁ切れるのも分かる

>>263
そのコードはcで使えるの？
使えるならともかく、Rust専用ならメンテナーが「そんなののメンテナンスで負担増えるのは嫌だからRustドライバー側でやってくれ」というのもわかる。

Rust for Linuxはこういうのの受け皿にならんのかしらん？

>>264
受け皿も何もそもそもRust for Linuxでやってる話だし
完全にRustドライバー側でやるからCには影響しないって言ってるわけ
具体的にメンテナンスの負担が増える理由を挙げてくれれば対応策も考えられるけど
「とにかくお前らを邪魔するためなら何でもする」って言ってるからどうしようもない

>>265
メンテナが「Rustは俺のサポート範囲に出てこないでドライバ内で閉じてやってくれ」と言うんだから、当面はrust fir linux でドライバーのテンプレートを作るなりCバインディングサポートライブラリを作るなりすればいいんじゃないんかね。

「Rust製の各デバイスドライバが独自のCバインディングを持つ不便な状況」というのもrust fir linuxでフレームワーク作ってサポートすれば解決するし。

互いにブラックボックス内でなにが起ってるのかわからないとすると困るけどね

コレコレこういうコードを書いたらこういう結果が出るはずなのに出ないとコード提示されても
相手が理解できなければこじれるだけ

>>266
そこで言う当面はってのは3-4年前の状況かな
今はもう準備も整って、Mac用のAsahiLinuxとかAndroidとかフォークしてる勢には普通に入ってる段階
だからそろそろ本体にって話になってるわけだけど、拒絶されるなら彼らはフォークに戻っていくだけだとは思う

>>256
Linusの返答も出てるな
https://x.com/lauriewired/status/1888018962811863109

内部の問題をSNSつかって文句言うなアホ
お前が問題じゃ

ここや他のスレでRustに意味のわからん難癖つける人が
いるのは5ちゃん民度のせいではないのがわかった

C++に似ている部分はC++と同じ程度に批判される
それとハイブリッド的な部分
100%ガソリンで動くか100%電気で動くかどっちかにしろという

>>268
該当コード用のメンテナがRustを使いこなすようになるか、専用のメンテナが別に現れるか、現在のメンテナが引退してRust推進のメンテナに代わるまでじゃない？

これはメンテナの複雑性管理＆管理ポリシーの問題だから、普及具合とかはあんまり関係ない。

色んなものがRust製になっていく中
最後まで残りそうなのが巨大でモノリシックなカーネルとブラウザになりそうだな

日本の古文漢文は残らないかもしれないが西洋では全部保存していて選択肢が増えるだけ
だから、向こうが世界の中心みたいな空気になる

firefoxはまだrust製にはならんの？

Linux カーネルは保守的な方針だろ。
数年前まで C89 が前提だったんだぞ。
この速度感で考えるなら Rust 導入なんてまだまだ時期尚早じゃね？

Firefoxのレンダリングエンジンは大分前からRust製（Servo）でしょ

>>278
Servoにそんな完成度はない
実験レベル

錆→癌

Mozillaお金なさすぎて色々と切り捨てて
RustもRust Foundationへ移管されたもんな
結果的にRustにとっては中核が安定してラッキーになったけどさ

＞ 2020年にMozillaがすべてのServo開発者を解雇した後、プロジェクトのガバナンスはLinux Foundation Europeに移管された。
＞ 開発作業は公式には同じGitHubリポジトリで続けられており、プロジェクト自体は完全にボランティア主導です。

C/C++その他の知識を蒸留してないわけがないから
コストもコスパもないんだよ

Pointers (this includes values of reference type) in Rust have two components.
- The pointer's "address" says where in memory the pointer is currently pointing.
- The pointer's "provenance" says where and when the pointer is allowed to access memory.
We have to know not only the address the pointer points to,
but also track which other pointer(s) it is "derived from".
Provenance is useful because it allows powerful optimizations.
Provenance can affect whether a program has undefined behavior.

Rust Tokyo 2024 開催レポート
https://gihyo.jp/article/2024/12/rust-tokyo-2024-report

edition = "2024" が来たね

https://softantenna.com/blog/linus-rust-policy/

Linus が一喝して技術的に合理的説明のない
rust拒否は許さないことで決着か

生メモリいじくるのが好きな人たちがいきなりrustやれって言われたらきつい気持ちはわかる
どうせメンテーなんてみんなジジイなんだし

rustが嫌でもやれなんて言ってないが

Linusの今回の発言は明瞭で
・Cだけ触りたい人はそのままRustを覚えなくてOK
・その代わりRustについて口を挟む権利はない
・CのAPIをその利用者は自由に使えてメンテナといえども用途用法に口を挟む権利はない

したがって今回もめていた「CのAPIの上にRustのAPIを設ける件」について
Cだけ触りたいメンテナは口を挟む権利はなくパッチを拒否する権利もない、ということ
大方の人々が考えていた通りに決着

口を出せない=メンテナ失格ということと受け取った

かつてカーネルを正しく修正した結果として (保証してない挙動に依存した) 間違ったアプリケーションのいくつかがまともに動かなくなったことがある。
そのときに Linux の理念としては技術的合理性でユーザー体験を損なってはならないということで間違っているアプリケーションに合わせて互換性が維持された。
ユーザは一方的な利用者に過ぎずカーネルに口出ししないなんてことはない。
絶対に、絶対に、絶対に、カーネルに口出しするよ。
まあそれが良いか悪いかは知らんけどな。

>>291
そういう具体性を欠いた屁理屈言って拒否するのは
やめろと怒られてるのだね

>>290
そういうデマを言うやつがいるとコミュニティー全体が嫌われるから止めるべき。

Linusが言っているのはせいぜい「Rustコードのメンテナじゃないだろ」ぐらいの話で、Linuxメンテナ失格とは全く言っていない。むしろメンテナが自分のメンテナンス範囲をCコードだけにするのを肯定している。
今回の件も、C APIユーザーとしてのRustコードがCコードとは独立した形で別のメンテナにメンテナンスされるんじゃないんかね。

着実にRust APIを増やしていこう
脱libc

Rustは清書用

じゃあRoughって言語も要るな

Rustはリファクタリングでの安定度も他より極めて高くて開発効率が良いので
まずは雑に書いて後から可読性を上げたり拡張性を上げたり実行効率性を上げたり普通に行われているね

>>296
クレート境界をダックタイピング化した言語が欲しいわ。

>>291
その動作は弊社製品の仕様です
（今後も動作は維持されます）

その動作は弊社製品の問題点です
（今後動作は変更されます）

>>298
それがC++かもしれませんね

>>298
ダックタイピングは各異なる型を統一的に安全に呼び出せる保証が人任せだから使うべきでない
トレイト境界を指定すれば安全が保証されるがそれはトレイトすなわち他言語で言うところのインターフェースに近い存在を仮定していてダックタイピングとは言い難い

>>301
>298のダックタイピングは静的ダックタイピングで構造的部分型のことね。
型の機能的な共通部分を部分型として統一的に扱うから、普通の型と同程度には安全かと。

>>298
Go だと型があるインターフェイスを満たす (満たすつもり) かどうかは明示的な宣言がない。
インターフェイスで定義されたのと同じメソッドを持っていればそのインターフェイスを実装したものと見做される。

>>302
まずその共通部分が存在する保証がない
次に共通部分があったとしてもその部分への任意のアクセスメソッドが完全に同一である保証がない
さらにダックタイピングで用意されるメソッドがその共通部分のみにアクセスされる保証がない
共通部分型方式には問題が山積み

一方でトレイト境界を用いると
共通部分を持たなくても安全に共通メソッドを増やすことができる

相変わらず日本語不自由だな

言語によるとしか言えない
その言語にある道具なら、それが便利なら使って問題ないと思う
C++だと標準ライブラリでもダックタイピングをごく普通に使うけど、それに文句を言う人もいないでしょ

C++のような古くてダサい言語は比較する意味ないだろ
ダサくて自己責任となるダッチタイピングはお似合いだが

Rust書きやすいって言ってるのは大体c++から移った人間でそういう人がここに集ってる
GC付きの言語から来たらそこまでは思わない

>>304
静的ダックタイピングとか構造的部分型はご存知で？

コンパイル時にメソッドとかプロパティとかの部分集合で互換性を判定しているので、通常の型と同じレベルで合致するよ。

>>304 に賛成

>>306
便利さと安全性は独立してるからな

>>310
>>304を理解できるなんて君は天才だねｗ

A:「〇〇な言語があったらいいのに」
B:「言語によるとしか言えない」
A:「・・・」

Structural Typingでバイナリ境界を超えて新しいメソッドを追加できるようにしてしまうと衝突時のデメリットがメリットを上回る
Rustにcoherenceがあるのと同じ

>>308
GCの有無は関係ない
異なる型に対するコードの共通化つまりジェネリクスの話

例えばクラスを使えば同じ基底を継承する派生同士は異なる型でも共通のメソッドやプロパティを使える
しかし同じクラス継承の関係しか扱えないのは制約がキツく各機能毎に継承で多重クラス継承など問題が多い

一方でダッチタイピングや構造的サブタイピングは無関係な型同士でも同じメソッドやプロパティがあるだけで暗黙に使える
しかし互換性がなく偶然同じメソッドやプロパティを持つ同士の利用をエラーにできない問題や暗黙であるため複雑化してくると分かりにくくなるなど問題が多い

そこで機能毎にインターフェース宣言と各型でのインターフェース利用宣言することで諸問題を解決し安全で保守しやすいコードにすることができる
そしてインターフェース名(機能名)が付くことで複数の機能の列挙や関係も宣言できるようになる
Rustではトレイトと称する

llmの3B当たりが吐き出す文章みたいで何を言ってるのか意味不明だな

丸一日調べてこれとか泣けてくるな
ついでにRustのトレイト問題も調べとけよ

>>313
最初の一文は違うだろ
A. 「(Rustにない、他の言語では使われてる機能) は問題だらけ」
っていう主張に対して反論されてるだけ

>>312
少なくとも君は馬鹿だよ

わからんけどtypescriptやれば

ま人生一度は型厨になるのは仕方ない

ダックタイピングは動的か静的かに関わらずデメリットが多すぎて使うべきではないよ
唯一のメリットはinterface宣言が不要だけどこれが害悪を招いちゃう
interface名がないから可読性が悪く保守性も低いのはもちろん利用方法に制限も

静的なダックタイピングにはinterface宣言もinterface名もあるやろ

>>323
名前をつけて宣言したらそれはinterfaceそのものだよ
名前も宣言もなしで共通のメソッド名など構造が同じなら動作することがダックタイピングだよ

ubyの罪は重い

Rustってまだオワコンになってなかったんだな

構造に頼るよりも、ジェネリック関数でトレイト境界で制約かけた方がRustっぽい気がする。
なんとなく。

>>324
上に出てきてるように構造的部分型(Strructural Subtyping)を含めた話
まあ俺もStrructural Subtypingを静的ダックタイピングと呼ぶのは
誤解を招きやすいからあまり賛同しないがそこは問題じゃないでしょ

>>327
ジェネリックの型パラメータをトレイトで制約するということと
その制約を満たしてるかどうかを型の構造に頼ってチェックするのは両立する話

共通する構造＆機能がある時に
・interface名(Rustではtrait名)を付けて宣言するか
・名付けずにダックタイピングするか
の違いが最も大きい
後者は様々な点で劣る

両者の中間的な位置付けにいるのがGo
Goでは各型に対するinterface実装宣言を省略できてしまうため
省略すると可読性や保守性で劣ることになる

その「保守性が劣る」というGoは世間的には保守しやすい言語と言われてるんだが
型で守るという意味ではなく、多くの人に分かりやすい簡易な構文だからという理由でだけど

各型に対するinterface実装宣言を省略すると可読性や保守性で劣る
その事実以外の話には言及していない

その可読性や保守性の劣化というのは現実にどの程度問題と言われてるの？
「自分は嫌い」というお気持ちじゃなくて？
あるいは「Rustが採用してないから正しい」とか？

一般的に必要な情報は暗黙ではなく明記されている方が保守性も高いんだよ
そして多くの人に分かりやすい
省略できるようにしたことはGoの仕様の失策だね

Goの場合は「省略できる」というよりも「書かない」というのが正しい
選択できるものではなく、常に書かないものだから

正直自分も好きではないし、だいぶクセのある言語だけど、世間的には受け入れられてる
世の中の人は案外そこまで型にこだわりはなくて、それよりも分かりやすさの方が好まれたりする
それは単に「考えが違う」というだけで、劣るとか優れてるとかいうものではない
(それなら何でGoは人気なの？ってなるし)

あとRust開発者はC++から来た人が多いと思うけど、C++のテンプレートは思いきり静的ダックタイプでしょ
あれで実際「可読性ガー」ってなるより、便利だと思う場面もあるよね？

>>334
明記されていたほうが分かりやすいというのは正しい。
その一方で、明記しなくても分かるような設計にしろ (分かり難くなるなら設計が誤っている) という哲学が Go の根底にある。

structural vs nominalならが安全性はnominalのほうが高いが
保守性や可読性はどちらか一方が常に優れてるわけではないな

Rustはよりメタルに近いOSやライブラリでの利用を重視してるから
安全性の面からより保守的な選択をしてる
coherenceとかもアプリケーション開発者観点だと不必要に厳しい

Goでは省略しちゃうことが多くて、
ある型についてどんなinterface群を満たしているのか、を把握するために、
対象となりそうな全てのinterface群の各々のメソッド群と見比べて、
そのメソッド群すべてを実装していることを確認することで、
ようやくそのinterfaceを満たしていることを把握できる。
たった1行を省略できる利便性(?)のために、大きく可読性が落ちているのは否めない。

gopls implementationとかで確認すればいいよ

今どき珍しい真面目なスレッドだな

>>330
静的ダックタイピングは明示的インターフェイスでも成り立つよ。>336で言うならテンプレートとコンセプトみたいにテンプレート引数の要件を明示するやり方。

>330の言い方なら、
共通する構造＆機能がある時に
・共通することを型としてあらかじめ宣言するか
・共通部分を使う時に判別するか
の違いですな。
後者は共通する構造＆機能の決定を実際に使用する時まで遅らせることができるので、型の設計時点で決めなくてはならない前者よりも設計の自由度が増す。

Adapterパターンのサポートが充実していれば問題を緩和できるけど、Rustて充実してたっけ？

Rustは各型で共通事項をあらかじめ宣言する必要がなく
共通する構造＆機能の決定を実際に使用する時まで遅らせて
それらが決まってから後から実装すればよいため
設計の自由度が高いね

>>343
あれ？どうやるんだっけ？

他人の書いたコードをインタフェースで抽象化したいときにGoのinterfaceは便利だけど
全て自分で管理する場合は明示的に宣伝した方がいいから選べるようにしてほしい

Javaの普通のinterfaceに加えてGoのinterface同時に使える言語が欲しい

>>341
少し考えれば理由はわかるはず

>>346
お？上から来たな

>>345
interfaceに関して欲しい機能はRustのトレイト境界の機能だろ
Javaには類似の境界型パラメータがあるが単相化しないため役に立たない

>>343
Rustで共通事項をあらかじめ宣言しないで、共通する構造＆機能を統一的に使うのってどうすればいいの？

Rustの型システムを考えると、(既存のコードを変更することなく) 共通する構造＆機能を新たに宣言して統一的に扱える、ということだよね？

リファクタリングをするのに既存のコードを変えないとか矛盾していて意味がわからん
後から共通メソッドをトレイト化すればいいだけだろ
それで困る人はいない

>>350
例えば標準ライブラリの型との共通部分を統一的に扱いたい場合、標準コードをリファクタリングして新しい共通Traitを切り出すのかしらん？

Rustでコーディングしたことないお客さんが来てるのか？
標準ライブラリのコード自体を書き換えなんてせずとも普通に行われていることだぞ

>>349
>>343が言ってるのはstructの定義時にそのstructがどのtraitを実装するかを(あらかじめ)宣言する必要はなく後から必要になった時にtraitの宣言及び実装をすればいいというだけの話

わざとずらしたことを書いてるから噛み合ってないんだよね

既に存在する共通する構造＆機能をポリモーフィックに扱いたい時にGoなら必要なのはインターフェース宣言だけ
既存のインターフェースに合致するものなら新しく宣言する必要もなくそのまま扱える

一方Rustの場合は新しいインターフェースを宣言して既存の構造体に対する新しいインターフェース用の実装をそれぞれ追加で書かない限りは使えない
それで済めばまだいい方で既存のインターフェースに適合させなければいけない場合は既存の構造体をラップする新しい構造体とその実装を逐一全部書いた上にインターフェースに対する実装も別途追加で書かないダメ

特に後者の手間は雪だるま式に膨れ上がるからライブラリのように他人に使わせるコードを書く場合は型の設計時点というより外部APIの設計時点で何を共通の構造&機能として使えるようにするか決めておく必要がある

> 既存のインターフェースに合致するものなら新しく宣言する必要もなくそのまま扱える

無茶苦茶だな
そんな意図しない全ての型に自動適用される危険な言語は使いたくないわ

Rustは明示的にimplしたものだけに適用されるから安全で使い勝手が良い

> 一方Rustの場合は新しいインターフェースを宣言して既存の構造体に対する新しいインターフェース用の実装をそれぞれ追加で書かない限りは使えない

そんなことはない
既にimpl Tにあるのだからimpl Trait for Tへ移動させるだけだぞ

> それで済めばまだいい方で既存のインターフェースに適合させなければいけない場合は既存の構造体をラップする新しい構造体とその実装を逐一全部書いた上にインターフェースに対する実装も別途追加で書かないダメ

そんなことはない
既存の構造体にそのままtraitメソッドを増やせる

Rustでコーディングしたことないお客さんがこのRustスレでRust叩きとは完全に荒らしだ

外部クレートで定義されたトレイトを別の外部クレートの型に対して実装するときはラップが必要じゃない？
要素1つのタプル構造体 (いわゆる new type) で済むような話だけど
インターフェースといってるあたり微妙にズレてる感はあるけど、「ラップする必要がある」という点自体は間違ってない

>>358
そんな話は誰もしていないよ
今話されているのはこれ

＞既に存在する共通する構造＆機能を
＞新しいインターフェース宣言

複数の型に共通事項が出てきたから
新たなトレイトを作って宣言する話が行われてる
ラップは不要

自分の管轄外の型に対して、自分の管轄外のトレイトを実装することだけは、安全のため禁止されているので、自分の型にするためのラップが必要
そんな特殊な例外的ケースを除けばラップはもちろん不要

最初からクレート境界を前提とした文脈だろ >>298
文脈読めよ

インターフェイス vs. ダックタイピング

ダックタイピングはインターフェイス名がないため可読性が著しく低い
インターフェイス名を使った制約も指定できない
必ずインターフェイス機能を使うべし

>>362
こういう簡潔なまとめ助かる

ダックタイピングは、意味が異なっていても、見かけの構造さえ同じなら、同一視してしまう問題もある
つまりうっかり間違えて用いても、エラーを検出できないため、安全性で劣る。

その見かけの構造さえも、複数の構造を含む場合など、
この型はどのダックタイピングで用いられているのか、読み手が認識するのに時間がかかってしまう。

これらの問題は、各型において、どのダックタイピングに用いられているのかの宣言がないことに起因している。
一方で、interfaceは「各型でどのinterfaceを用いているのか」の宣言があるため、どちらの問題も生じない。

>>327 奇遇ですね私もです

>>333
実行前(コンパイル時など)に問題が表面化することと
実行後に問題が表面化することの違いは果てしなく大きい

>>339
ほんそれ

>>342
だからRustは清書用って言われるんだよ

>>351-352
type alias でほぼ何でもありな状態に出来るけど
他人のcrateとさらに他人のcrateを混ぜてると詰む

>>353
君こそコーディングしたことないだろ

ああ 353 は引用なのか？
354 と 353 が同一人物ならきもいが
354 の言ってることが実情

>>356
↑こういうのが混乱を招くからやめれ

>>359-360
struct に限ってはそうだね

>>342
Rustでは最初から共通部分があることを意識する必要がなく
そのような場合でも設計の自由度が高い
共通部分が生じたことに後から気付いた時点でそのためのトレイトを後から宣言すればよい

>>354
Rustならばラップは必要なく、トレイト宣言をしてトレイト側へメソッドを移動するだけで簡単に済む
impl Foo {
　fn method(&self, ...
}
impl Bar {
　fn method(&self, ...
}
と複数の型に共通メソッドがあり、それをトレイトで共通に扱えるようにしたければ

// トレイト宣言
trait TraitName {
　fn method(&self, ...
}
// トレイト実装
impl TraitName for Foo {
　fn method(&self, ...
}
impl TraitName for Bar {
　fn method(&self, ...
}
つまり「impl Foo」から
「impl TraitName for Foo」へ移すだけで済む
今回の例なら差分タイプ量は「TraitName for」のみ

struct のときだけね

>>376
enumでも他でも同じ

フーン(ﾆﾔﾆﾔ)

伸びてると思ったら複オジの類友が増えただけだったorz

>>376
structに限らず全ての型に対してトレイト実装によりメソッドを増やせるよ

&str(実質&[u8]でもVec<u8>でも)の末尾に
ゴミで良いから毎回必ず'\0'付ける仕様にしといて欲しかった

>>381
'\0'に限らず任意の値を終端として型を定義できるZigの勝利だね

やっぱ崩れたかw
346みたいな偉そうな奴がいるとなw

死んだスレが生き返ることなどない

>>381
必要な時だけ付けりゃいいじゃん
不要なものを常時付けとけとか頭おかしい

異なる方式を混ぜ合わせると両方を協調するのにミスが入りやすい。
ゼロ終端方式とファットポインタ方式に常に矛盾が生じないように維持するくらいなら必要なときに変換するほうがマシ。

>>375
>つまり「impl Foo」から
>「impl TraitName for Foo」へ移すだけで済む
>今回の例なら差分タイプ量は「TraitName for」のみ
フィボナッチみたいなトイコードしか書いたことがないと
こんな意味のない破壊的な変更を無自覚に書いてしまうんだな

>>381
"abc"の部分文字列"ab"を参照する時に元の文字列が"ab\0"になるけどいい？

>>381
&strはStringや(別の)strの任意の部分文字列を参照する型
もし末尾に'\0'を付加すると次の文字を'\0'で上書きするため原理的に不可能
Rustで'\0'終端文字列はCStr/CStringを使う
リテラルならc"ABCDE"

ちなみにC/C++で部分文字列を扱うと
同じ問題が起きるため別領域へコピーして末尾'\0'を付加する
さらに途中に'\0'を置くと千切れる問題や
長さを知るために'\0'まで要走査の問題があるので
Rustのstr/Stringでは'\0'終端文字列としていない

>>387
新たなトレイトを作ってメソッドを移しても破壊的な変更にならない
もちろん移すだけでは意味はないが
使う側でそのトレイト境界を用いてコードの共通化が可能となるため普通に行なわれる

>>389
いつの時代のC++だよｗ

>>391
昔も今もC + +のs t r i n g関数s u b s t r (開始位置, サイズ)は別の領域を確保してコピーだよ
\0終端するためにコピーは避けられないね

ちなみにライブラリ実装依存だろうけど
毎回ヒープ領域確保はコストが大きすぎるため
結果が15文字までならば静的に各16バイトの領域を事前に持っていてそこを使って頑張っていたりはする
でもそこへのコピーは避けられないね

>>390
うわぇー
なんでそんな嘘を吐くの？
もしかして破壊的変更の意味を知らない？

>>391
C++ の中だけでやるなら今は range を中心にライブラリが編成されてるから文字列の一部を取り出すのにコピーは必要ないしゼロ終端も不要だが、ここでは (古いライブラリなり API なりの都合で) ゼロ終端が必要になったときはという前提の話をしてるんだぞ。
外の世界は言語の都合に合わせて勝手に変わってくれたりはしない。
モダンな C++ を使っていても外と繋がる境界では外の都合に合わせなきゃしょうがないんだ。

>>394
Rustの中だけでやるなら文字列の一部を取り出すのにコピーは必要ないしゼロ終端も不要だが、ここでは (古いライブラリなり API なりの都合で) ゼロ終端が必要になったときはという前提の話をしてるんだぞ。
外の世界は言語の都合に合わせて勝手に変わってくれたりはしない。
モダンなRustを使っていても外と繋がる境界では外の都合に合わせなきゃしょうがないんだ。

君の言う前提に沿えば>>389の比較は無意味

>>395
「いつの時代の C++ だよ」に対していつの時代でもそうだよと言ってるだけ。
>>389 には興味ない。

>>395
あらためて >>389 を見たら「ゼロ終端にするにはコピーが必要なのは同じだ (型の整理の仕方は違っても)」というのが趣旨だから結論が同じなのは意図どおりだろ。

>>389
CString::new(string)で0終端してくれて
c"ABCDE"は最初から0終端されてて便利だね

// 固定文字列は c"..." リテラルで作成
let c1 = c"ABCDE"; // &CStr型
// 文字列を組み立てる場合はStringで作成しておいて
let s = ('A'..='E').collect::<String>();
// そのStringを消費して0終端してくれる (途中に0があるとError)
let c2 = CString::new(s).unwrap();
// 左右どちらも &CStr型の c"ABCDE" で一致
assert_eq!(c1, &*c2);

このスレいつからﾜｯﾁｮｲとかIDとか無くなった？

隔離スレにそんなもん必要ねえよ

ﾜｯﾁｮｲとかIDがあると自演するのに不便だからいらない

本スレどこ？

まともに他人の意見を尊重できる人たちが集まり議論が行われればそこが本スレになるだろうが、期待するだけ無駄じゃろ

>>398
自分で'\0'プッシュすればええやんと以前は思っていたけど
ミスがないことを型システムに保証してもらえる安心感

>>402
DかZにおいで

自分でNULL終端しようとする老害は
安全を保証する型システムと相性悪い

[c_char]が[u8]だと思ってたら[i8]だったでごじゃる

c_charは処理系依存っぽいからu8かi8に決め打ちするならc_ucharかc_scharにキャストした方がいい
ターゲット変更した時にコンパイラに文句言われる可能性がある

\0終端じゃないと困るってcやc++から来た人だろ…
老害っているんだな

>>409
OS の要求ならしょうがないだろ……
適当なラッパー作るにしてもそのラッパーの中ではゼロ終端にしないわけにはいかん。

>>398
あとはCString/CStrからの変換だな
&[u8]として扱えるのは当然として

// CStringを消費して Stringとして扱う (非UTF8だとError)
let c = CString::new([b'A', b'B', b'C', b'D', b'E']).unwrap();
assert_eq!(c.into_string().unwrap(), String::from("ABCDE"));

// &Cstrを &strとして扱う (非UTF8だとError)
assert_eq!(c"ABCDE".to_str().unwrap(), "ABCDE");

// &Cstrを Cow<str> にする
// UTF8なら &strとして扱い Cow::Borrowed(&str)型
let cow = c"ABCDE".to_string_lossy();
assert_eq!(cow, Cow::<str>::Borrowed("ABCDE"));
// 非UTF8部分があると U+FFFD置換Stringにして Cow::Owned(String)型
let cow = c"AB\xccDE".to_string_lossy();
assert_eq!(cow, Cow::<str>::Owned(String::from("AB\u{FFFD}DE")));

いずれも'\0'の存在は気にしなくていい

&selfで読み取り参照のまま、別の型の読み取り参照に読み替えるのはもちろん、
selfで消費してしまい、確保メモリをそのまま活用して、別の型に読み替えるのが効率ええんやな

>> http://2chb.net/r/tech/1708677472/784

Ruby (が採用している CSI 方式) での文字列オブジェクトはそれぞれどの文字コードであるかの情報を持っていて処理系は各文字コードの処理方法を知っている。
つまり文字列を扱うあらゆる箇所で様々な文字コードごとの処理をやってる。
それが先進的か？
文字コードが統一できない世界でも「なんとかする」方法だろ。

内部的には統一した文字コードで扱い、様々な文字コードを扱いたければ入出力の段階で変換するというのが Rust 的なスタイルを含む現代的なプログラムが目指すところで、そのために Unicode はあるゆる文字コードから「変換可能であること」を指向してる。
とはいえ、これが先進的と言えるわけでもなく総合的に考えて現代の事情に合うやり方ってだけだ。

様々な文字コードの変なところも含めて Unicode に取り込んでいるのは既存のテキストのデータを (情報を失うことなく) 移行できなきゃ Unicode に統一されていかないからで、同じ駄目なら統一されていないことによる駄目さより統一されてる駄目さのほうがかなりマシという価値観による。
いろんな駄目さに個別に対処するのではなくデカい駄目に皆で立ち向かう。

人間の言語が数千年・数万年の歴史的経緯の積み重ねなので文字も駄目だし文字コードも駄目。
根本的に駄目なものはどう扱ったって駄目。
綺麗なやり方で扱わないのは綺麗なやり方が存在しないから。。

AIで3行程度にまとめてから書き込んてくれる？

ネットもファイルもUTF-8で統一しちゃうのが吉
外部のcharset=Shift_JISとか扱わないといけない分だけencoding_rs _io

>>356
>>375
>既にimpl Tにあるのだからimpl Trait for Tへ移動させるだけだぞ

pub 付いてると知名的なので doubt

crateとかdocsの事考えるとそんな単純な話じゃないんだよ
実践的なコード描いてない人か

歴史的にマクロ＝悪の固定観念もってるプログラマも多い気がするから
macro_rules!()はtemplate!()に改名した方がいいかもしれんね
impl Traitとかマクロ使わないと面倒な場合が多い

Rustってfor_eachのclosureのなかでbreak出来ないのです

>>418
名前は Scheme の syntax-rules から持ってきたんだと思う。

>>419
map_whileやtake_whileか
try_for_eachやtry_foldを使えば？
ControlFlowを使って自分で作る方法もある

>>419
クロージャは(変数をキャプチャできる)関数の一種なのでbreakなんて概念はない
for_eachはクロージャを引数に取る高階関数なのでbreakなんて概念はない
次々とやってくる「全ての各エレメント」に対して何度もそのクロージャを呼び出すだけなのでクロージャで早期returnしようとしても全てのエレメントに対して処理される
やりたいことはおそらく次々とやってくるエレメントの途中で処理を終えたいのだろうからfor_eachではなく以下のイテレーターメソッドを使う

要点をまとめる力って大事だな

クロージャが関数の一種なのか関数がクロージャの一種なのかそれが問題だ

大雑把な説明としては、
クロージャは(キャプチャがある)関数の一種、
関数は(キャプチャのない)クロージャの一種、
と言っても構わないが、
実際には、
Fnで使えるのはsafeなfnのみ、
fnにコアースできるのはキャプチャのないFnのみ、
といった関係。

クロージャと言えばFn(&mut T) -> ()みたいな定義が許容されてるのはなんでなの？
間違った使い方をすればownershipルールに違反してエラーにはなるだろうけどFnMut(&mut T)->()にするよう弾いたほうがよくない？

ここ観るのが早い
https://qiita.com/lo48576/items/34887794c146042aebf1

試しに見てみたがリファレンスと同じ情報の劣化版なので見る価値なし(個人の感想です)

>try_for_each(): Iterator<T> -> (T -> Try<B=()>) -> Try<B=()>
>失敗するかもしれない関数について for_each 的な操作を行う関数。
>これといって特記すべきこともないが、今まで for で書いていたものがシンプルにできる、ありがたい関数である。
>もし成功時にも何らかの意味ある値を返したいのであれば、 try_fold を使うべきである。

例えばtry_for_eachの最後の行の解説とか
ツッコミどころが盛り沢山

>>427
クロージャの引数は、毎回変わるのだから常に何をしても自由であり、引数を消費してしまおうが、可変参照があって参照先を書き換えようが自由。
クロージャで制限がありうるのはキャプチャした値のみ。

Fnはキャプチャした値がある時に、それを読み取り参照しようが自由だが、書き換えたり消費したりはできないという意味。
FnMutはキャプチャした値を読み取り参照しようが書き換えようが自由だが、消費してはいけないという意味。
FnOnceはキャプチャした値を消費しようが書き換えようが参照しようが自由という意味。
キャプチャ値を消費をしてもしなくても自由ということは、2回以上の実行は不可で、そのクロージャの実行は1回だけという意味、だからFnOnceという名前。

トレイト間の関係は「Fn: FnMut」かつ「FnMut: FnOnce」、つまりFnOnceは他の最上位のスーパートレイト。
集合で見ると、FnOnce⊃FnMut⊃Fnとなり、Fnが最も制限がきつくて集合としては小さい。
蛇足だが、fnはさらに制限がきつくて読み取り参照キャプチャすら許容されないから、Fn⊃(safeなfnの集合)となって、safeなfnは任意のクロージャの位置で代わりに使える。

例えば、LazyLock::new(f: F)のような、1回しか指定クロージャが実行されない高階関数では、最も緩いFnOnceでトレイト境界「F: FnOnce」を指定できる。
逆に何度もクロージャが実行されるIterator::fold(init, f: F )では、初期値initは消費されるが、fがキャプチャした値が消費されては困るためFnOnceではダメで「F: FnMut」となり、fの引数二つは毎回消費できる。

>>428
一番重要な独自の分類方法を最初にまとめて書かないからクソ記事になる

>>430
>クロージャの引数は、毎回変わるのだから常に何をしても自由であり

なるほど。言われてみれば納得。
ありがとう

なんでtypescriptのソースをrustに移植できないの？
プログラムなんだから不可能ってことはないでしょ？

>>433
出来ることと効果的に出来ることは別というシンプルな話。

TypeScriptのコンパイラはその利用の多さからもっと高速さを狙ってC/C++・Rust・ZigなどのGC非依存言語で書く価値がありブラウザ上Wasm実行の観点からもそうすべきだったが
担当者の能力不足のため遅いGC依存言語から速いGC依存言語へ書き換えるだけで終わってしまった
そのため早くもWasmでの実行が遅いという指摘が出ている

要するに、GC依存症の人にはrustは過ぎた物って事か。

アンダース・ヘルスバーグが能力不足なんて話があるかいな。
Rust や C# が得意なのにあえて Go を選定したんだぞ。
WASM 上で遅いのは WASM のほうの性能不足だ。
Go の優秀さはランタイムサポートの作り込みにあり、それが十全に発揮されない環境ではそりゃ遅い。

Rustで書けばwasmの件も問題なかったわけだからGoという中途半端な言語を選んだ選択ミスだな～

WASM ってそんなに絶対に考慮が必要なほど重要なプラットフォームか？
コンパイラを WASM 上で動かそうとする判断をするやつがいたらそのほうが選択ミスだろ。

TypeScript からの移植という前提があったから Go が比較的やりやすいと判断された。
関数単位でほとんど一対一のベタ移植を出来てる。

GC言語で書かれたプログラムをRustに移植しようとするとプログラムの構造を大幅に変えなきゃいけないからな

まあRustでのプロトタイピングも絶対やってるだろうけど

スパゲッティになってる下手なプログラムは、Rustで書く時にそれをほどいてまともなプログラムにしなきゃいけないもんね
それにより効率改善や機能拡張などの保守性も格段にアップするから、当たり前で必須な作業なんだけど、手間を惜しんだのかね

また的外れなことを
普段Rust書いてれば嫌でも分かることなんだけどなぁ

TypeScript で書いてあることの弊害としてランタイム (つまりは JavaScript 実行環境) がウェブ用に最適化されてることを挙げてる。
ウェブのプログラムではリクエストごとのターンアラウンドタイムが重要だが、コンパイラは時間あたりの計算量が重要で、違う戦略が要る。

コードの保守などはとりたてて問題になっていない。
もしより良く出来る余地があったとしても組織としてコストを支払うほどの価値じゃない。

Rustの話題だとダンマリなのに
どうでもいい他の言語の話だと連投するヤツいつもいるな

政治や流行に流されない決断ができる土壌があるのは良い組織
動画を見るとヘルスバーグの優秀さがひしひしと伝わってくる
windowsのPMとは大違い

一通りいろんな言語でプロトタイプコンパイラー作ってみたって動画内でも言ってたじゃねーか。で、Goが一番一対一で手堅く移植できる上に十分に速度アップもしたと言うことかと
パランスの問題だよ。時間をかけてリターンがどれだけあるか。だって営利企業だしプログラマーは無料じゃない。実際、方針決まってからはギットハブ・コパイロットに大部分やらせたんだろうがな

なんでfirefoxのソースをrustにできないの？
プログラムなんだから不可能ってことはないでしょ？

新たに作るものはRust一択になりつつあるが
既に別の言語で書かれているものはそれを負の遺産として考慮しなければいけなくなる
サンクコスト効果コンコルド効果に加え既存言語プログラマの抵抗勢力も足を引っ張る要因となる

>>448
> 新たに作るものはRust一択になりつつあるが

んなこたーない。
選択肢として普通のものになったが、あくまで選択肢のひとつだ。

日本語を型付きにして文法的に正しく無い書き込みは投稿ボタン押した時点で弾くようにならんかな。必ず日本語コンパイルエラー無しなのを確認してからしか誰も会話しちゃいけないなら世の中より良くなるはず。頭の中がスッキリする。

型への幻想期は誰しもが通る
そのうち人間には無理なことを悟るまでがテンプレ

>>448
頭おかしい

状況に応じて適切な言語を選択するのが普通の技術者

特定の言語に入信して
なんでRustじゃないんだなんでC#じゃないんだと
感情的にコメントを書いてるやつが多くてすごく滑稽

>>451
ちょろっと書く程度なら何でもいいけど
まともに開発するなら強い静的型付け言語が開発効率面から必須

「あると良いね」くらいじゃね
DropboxもPythonだったんだから、Dropboxくらいちゃんとしたサービスのレベルまで行っても必要条件であることはありえない
そしてそれよりデカいサービスの立ち上げは言語どうこうとかよりそもそもそのサービスが参入できる隙間を見つけて高速に参入することが重要。

やりたければどんな言語でも手間暇かければできるのは当たり前
強い静的型付け言語で構築しないと開発保守効率が劣り時間と労力の無駄

効率の話か
それで言うと、ビジネス感覚のある人が好まない言語はそもそもビジネスが成功しないから開発するだけ無駄だな

時間をかけないためにスタートアップは動的言語を使ってるんだけどな

Facebook, Instagram, Youtube, Github, Twitterと例をあげればキリがない

ここまでIT時代になる前だけじゃね

スタートアップは静的型付言語しか勝たん
https://zenn.dev/ficilcom/articles/static-typing-for-startup

動的型付け言語を捨てて静的型付け言語に移行したとか
静的型付け拡張の開発を主導してるような…

あと最近はスタートアップでフルスタック
typescriptにしてるところは珍しくない

それぞれに適したものがあっても関連するプロジェクト全体で一貫した言語を使った方がスキルセットの管理が単純になるから運用が楽になることはある。
ウェブ系だと JavaScript か AltJS は避けられないのでそれに寄ってしまうのは仕方がない。

自分の頭で考えられない人ほど
またスキルや経験の幅が狭い人ほど
特定の技術を宗教化して盲信しやすい

そうなるとますます自分の頭で考えられなくなり
どんな不都合な事実があろうと
教義に反さないよう都合よく解釈しようとする

優秀な技術者の対極

>>462
フロントサイドはTypeScript＋WebAssemblyで良いけど
サーバーサイドまでTS/JSはリソースの無駄遣いなんだよね

もちろんまだ技術の発展途中なのでSSG/SSRをハイドレーションしてCSRするなら
その部分に限ってTS/JSでコード共通化は理解できるけどね

>>460
最も普及しているC++を消している時点で論外。

静的であろうと動的であろうと重要なのは(関数呼び出しなどの)コードの接続面・境界面の互換性であって、オブジェクト操作の互換性があれば良い。

動的型付けはこの互換性が実行時でないと判定されないのが問題であって、コード開発時(コンパイル)等に互換性を判定する仕組みがあれば問題無くなる。
コード解析は貧弱なので役に立たないが、静的インターフェイスのサポートなどで改善するだろう(今はそういうの無いけど)

静的型付けは互換性の判定のために型の命名を強制されるので、設計の柔軟性が無いなどの問題を持つ。こちらもC++コンセプトのよう静的インターフェイスで改善するので、今後は変数のコンセプト対応のようなインターフェイス改善で解決していくだろう。

RustのTrait境界もコンセプトのような柔軟性が欲しいところ。

>>458
スタートアップ時は動的型言語で造って
軌道に乗ったら静的型言語で造り治す例もあるが

>>462
https://qiita.com/YukiMiyatake/items/9904ed5b481e3f307bba
わろす

>>468
さすが書き手も読み手もQiita品質
テラワロス

「トレイト境界」などという完全な誤訳をいつまで使い続けるのかね？

わざわざBoundsと言ってる意味を考えてみてはどうか
第一言語が英語の俺からすると境界で違和感ない
お前は日本語が怪しいだろと言われれば確かにその通りだが

限界とか条件ならbounds じゃなくてlimitationだしな。

interface的な意味合いが強いのにinterfaceにしなかった理由はなんでかね？

>>472
英単語としてはそうかもしれんが、他の言語の用語にある interface と似た部分はありつつもやっぱり違うし、そこらへんは違う語をあてたほうが自然だと思う。

通勤電車乗ってなくてうらやましい

> 目的地を意味する表現です。 例文. This train is bound for Tokyo station. この電車は東京駅 ...

>>474
それは「bound for」という熟語だし、さらに言えば
bound 境界
for 方向(対象までの間が主眼)
の組み合わせでそういう意味になるから、boundの例示で出すのは不適切かと。

inboundも外→内の境界付近のイメージが強いし、なんか良い例無いんかね。

circleじゃなくてdiskの方に適用可能範囲があるから、境界を印象付けてもしょうがない
範囲や領域って言えばいい

>>472
Java語は要らんのだよ

清々しいまでにバカばっかだなwww

>>471
>わざわざBoundsと言ってる意味を考えてみてはどうか
そのセリフそっくりそのまま返すわ
本当に英語ネイティブなら日本語の「境界」の意味を知らんのだろうな

>>472
>限界とか条件ならbounds じゃなくてlimitationだしな
boundsをそのまま表現できる日本語の二字熟語は存在しないから完璧な訳語というのはない
完全な誤訳というのはあるけれども

>>475
おいおいｗｗ
bound forのboundとtrait boundsのboundはスペルが同じだけで意味も語源も違う単語だぞ
何が「bound 境界」と「for 方向(対象までの間が主眼)」の組み合わせてそういう意味になるだよ
不適切にもほどがあるかど。

束縛を誤用してる言語なんだから