Rust part27

**デフォルトの名無しさん** · 2024/12/02(月) 22:32:50.31

公式
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
https://mevius.5ch.net/test/read.cgi/tech/1726838318/

ﾜｯﾁｮｲスレ
プログラミング言語 Rust 4【ﾜｯﾁｮｲ】
https://mevius.5ch.net/test/read.cgi/tech/1514107621/

**デフォルトの名無しさん** · 2025/02/25(火) 18:17:51.25

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

**デフォルトの名無しさん** · 2025/02/25(火) 18:41:48.14

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

**デフォルトの名無しさん** · 2025/02/26(水) 04:07:17.14

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

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

**デフォルトの名無しさん** · 2025/02/26(水) 19:09:22.06

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

**デフォルトの名無しさん** · 2025/02/27(木) 14:26:32.38

Rustは清書用

**デフォルトの名無しさん** · 2025/02/27(木) 21:14:53.56

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

**デフォルトの名無しさん** · 2025/02/27(木) 23:34:31.56

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

**デフォルトの名無しさん** · 2025/02/28(金) 08:15:36.47

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

**デフォルトの名無しさん** · 2025/02/28(金) 12:17:20.44

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

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

**デフォルトの名無しさん** · 2025/02/28(金) 12:19:57.96

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

**デフォルトの名無しさん** · 2025/02/28(金) 22:27:33.84

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

**デフォルトの名無しさん** · 2025/02/28(金) 22:51:15.56

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

**デフォルトの名無しさん** · 2025/02/28(金) 23:05:54.93

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

**デフォルトの名無しさん** · 2025/02/28(金) 23:49:44.86

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

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

**デフォルトの名無しさん** · 2025/03/01(土) 00:09:58.46

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

**デフォルトの名無しさん** · 2025/03/01(土) 08:37:01.16

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

**デフォルトの名無しさん** · 2025/03/01(土) 08:57:54.01

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

**デフォルトの名無しさん** · 2025/03/01(土) 09:10:51.88

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

**デフォルトの名無しさん** · 2025/03/01(土) 09:47:12.55

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

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

**デフォルトの名無しさん** · 2025/03/01(土) 11:24:22.93

>>304 に賛成

**デフォルトの名無しさん** · 2025/03/01(土) 11:25:33.81

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

**デフォルトの名無しさん** · 2025/03/01(土) 11:39:32.69

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

**デフォルトの名無しさん** · 2025/03/01(土) 13:10:29.22

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

**デフォルトの名無しさん** · 2025/03/01(土) 18:25:43.33

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

**デフォルトの名無しさん** · 2025/03/01(土) 22:44:41.75

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

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

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

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

**デフォルトの名無しさん** · 2025/03/01(土) 22:55:40.18

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

**デフォルトの名無しさん** · 2025/03/02(日) 00:27:51.62

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

**デフォルトの名無しさん** · 2025/03/02(日) 08:35:08.13

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

**デフォルトの名無しさん** · 2025/03/02(日) 15:32:34.86

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

**デフォルトの名無しさん** · 2025/03/02(日) 17:14:53.44

わからんけどtypescriptやれば

**デフォルトの名無しさん** · 2025/03/02(日) 18:00:38.37

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

**デフォルトの名無しさん** · 2025/03/02(日) 18:29:41.49

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

**デフォルトの名無しさん** · 2025/03/02(日) 19:02:58.00

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

**デフォルトの名無しさん** · 2025/03/02(日) 19:17:03.00

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

**デフォルトの名無しさん** · 2025/03/02(日) 21:10:41.61

ubyの罪は重い

**デフォルトの名無しさん** · 2025/03/02(日) 21:55:50.48

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

**デフォルトの名無しさん** · 2025/03/02(日) 22:12:16.30

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

**デフォルトの名無しさん** · 2025/03/02(日) 22:50:29.46

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

**デフォルトの名無しさん** · 2025/03/02(日) 23:00:19.17

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

**デフォルトの名無しさん** · 2025/03/02(日) 23:17:39.99

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

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

**デフォルトの名無しさん** · 2025/03/02(日) 23:37:21.79

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

**デフォルトの名無しさん** · 2025/03/02(日) 23:44:33.72

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

**デフォルトの名無しさん** · 2025/03/02(日) 23:54:11.22

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

**デフォルトの名無しさん** · 2025/03/02(日) 23:57:06.79

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

**デフォルトの名無しさん** · 2025/03/03(月) 00:08:35.40

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 00:11:38.35

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

**デフォルトの名無しさん** · 2025/03/03(月) 00:12:13.08

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

**デフォルトの名無しさん** · 2025/03/03(月) 00:19:18.53

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 00:25:34.97

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

**デフォルトの名無しさん** · 2025/03/03(月) 01:43:43.47

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

**デフォルトの名無しさん** · 2025/03/03(月) 03:55:57.34

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

**デフォルトの名無しさん** · 2025/03/03(月) 04:54:41.57

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

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 06:07:05.65

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

**デフォルトの名無しさん** · 2025/03/03(月) 07:42:47.63

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

**デフォルトの名無しさん** · 2025/03/03(月) 10:32:52.62

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 10:43:32.37

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

**デフォルトの名無しさん** · 2025/03/03(月) 10:47:29.58

>>346
お？上から来たな

**デフォルトの名無しさん** · 2025/03/03(月) 19:22:07.10

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

**デフォルトの名無しさん** · 2025/03/03(月) 19:49:07.58

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 19:56:00.40

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

**デフォルトの名無しさん** · 2025/03/03(月) 21:42:58.25

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

**デフォルトの名無しさん** · 2025/03/03(月) 22:28:07.80

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

**デフォルトの名無しさん** · 2025/03/03(月) 22:56:04.92

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 23:07:24.80

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

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 23:24:45.25

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

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 23:29:41.09

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

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

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

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

**デフォルトの名無しさん** · 2025/03/03(月) 23:46:24.87

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

**デフォルトの名無しさん** · 2025/03/03(月) 23:56:56.53

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

**デフォルトの名無しさん** · 2025/03/04(火) 00:10:16.92

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

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

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

**デフォルトの名無しさん** · 2025/03/04(火) 00:26:54.32

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

**デフォルトの名無しさん** · 2025/03/04(火) 01:25:48.23

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

**デフォルトの名無しさん** · 2025/03/04(火) 01:53:29.12

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

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

**デフォルトの名無しさん** · 2025/03/04(火) 02:35:55.33

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

**デフォルトの名無しさん** · 2025/03/04(火) 06:51:13.78

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

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

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

**デフォルトの名無しさん** · 2025/03/04(火) 09:45:00.92

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

**デフォルトの名無しさん** · 2025/03/04(火) 09:47:17.60

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

**デフォルトの名無しさん** · 2025/03/04(火) 09:50:16.00

>>339
ほんそれ

**デフォルトの名無しさん** · 2025/03/04(火) 09:52:06.99

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

**デフォルトの名無しさん** · 2025/03/04(火) 09:55:52.32

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

**デフォルトの名無しさん** · 2025/03/04(火) 09:57:24.96

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

**デフォルトの名無しさん** · 2025/03/04(火) 10:00:12.78

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

**デフォルトの名無しさん** · 2025/03/04(火) 10:02:37.01

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

**デフォルトの名無しさん** · 2025/03/04(火) 10:09:07.10

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

**デフォルトの名無しさん** · 2025/03/04(火) 11:30:33.83

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

**デフォルトの名無しさん** · 2025/03/04(火) 11:34:47.54

>>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」のみ

**デフォルトの名無しさん** · 2025/03/04(火) 12:03:00.52

struct のときだけね

**デフォルトの名無しさん** · 2025/03/04(火) 12:04:58.27

>>376
enumでも他でも同じ

**デフォルトの名無しさん** · 2025/03/04(火) 12:18:25.90

フーン(ﾆﾔﾆﾔ)

**デフォルトの名無しさん** · 2025/03/04(火) 12:40:56.52

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

**デフォルトの名無しさん** · 2025/03/04(火) 12:45:41.91

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

**デフォルトの名無しさん** · 2025/03/04(火) 12:58:42.56

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

**デフォルトの名無しさん** · 2025/03/04(火) 13:19:59.57

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

**デフォルトの名無しさん** · 2025/03/04(火) 13:44:40.50

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

**デフォルトの名無しさん** · 2025/03/04(火) 13:53:15.88

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

**デフォルトの名無しさん** · 2025/03/04(火) 15:55:00.59

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

**デフォルトの名無しさん** · 2025/03/04(火) 16:14:05.76

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

**デフォルトの名無しさん** · 2025/03/04(火) 16:16:40.93

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

**デフォルトの名無しさん** · 2025/03/04(火) 16:28:38.12

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

**デフォルトの名無しさん** · 2025/03/04(火) 17:42:39.60

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

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

**デフォルトの名無しさん** · 2025/03/04(火) 17:44:45.66

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