Rust part16

**デフォルトの名無しさん** · 2022/06/27(月) 08:17:03.45

公式
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を学ぶ際に犯しがちな12の過ち
https://dystroy.org/blog/how-not-to-learn-rust

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

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

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

**デフォルトの名無しさん** · 2022/09/19(月) 21:34:13.52

>>738
達成したいことが特にないらしいからなんとも言えないけど enum を使っても近いことはできるんじゃないかな。

enum Same{SameA(型A),SameB(型B)}

みたいにしてやれば、Same 経由で扱う限り実装は増やせないぞ。

**デフォルトの名無しさん** · 2022/09/19(月) 22:48:26.11

>>739-740
実装を追加させないテクニックのひとつとして有用ですし紹介はありがたいです。
しかしそれだと Sealed を実装した型だけにしか使えず、 >>738 で示したような汎用的に型を比較するトレイトには使えないですよね。
この Same のように機能するトレイトに実装を追加させないというのは前提と考えて欲しいです。

>>741
そういうレスが付くことを避けたいから最後の文をつけたつもりなんですが……。
Rust の初心者として様々な言語機能を理解したいという立場で疑問に思った部分を抜き出し、
説明のために前提条件を設定したのであって、前提条件の部分自体は解決したい課題ではないです。

いわゆるXY問題というものの存在は承知しておりますので
解決したい大元の問題を示さないというのがモヤモヤするだろうなというのはわかります。
わかりますが、大元の問題というものはありません。
この範囲で完結するパズルだと思ってください。

**デフォルトの名無しさん** · 2022/09/20(火) 00:14:22.92

2つの矛盾してる要求を同時に実現は無理だわな

**デフォルトの名無しさん** · 2022/09/20(火) 00:42:08.53

impl Foo for Tが存在する時点で他の型にFoo実装しようとするとconflictしなかったっけ

**デフォルトの名無しさん** · 2022/09/20(火) 00:43:28.04

fundamentalな型に一通り実装しておけば良さそう

**デフォルトの名無しさん** · 2022/09/20(火) 00:48:25.82

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=02e7851289dd00c9ffc8679ad68644d9

**デフォルトの名無しさん** · 2022/09/20(火) 00:50:06.23

fundamental云々はcoherent ruleの話でconflictとは関係なかったわ

**738** · 2022/09/20(火) 01:17:29.77

なるほど、 C++ と違って特殊化にならないからより狭い範囲の実装は追加できないんですね。
&T とか &mut T とかも先に実装しておけば追加の余地をなくせると。
&T とか &mut T とか以外にどういうのがありえますかね？

**デフォルトの名無しさん** · 2022/09/20(火) 01:40:45.09

>>743
Sealedも<T>にすればいいんじゃないの
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=dadd7e289ec4e5bb9746015ac093a9bc

**738** · 2022/09/20(火) 01:53:09.66

>>750
ありがとうございます。
言われてみれば当然のような感じですがまだまだ私は Rust らしい考え方が出来ていないようです。

**デフォルトの名無しさん** · 2022/09/20(火) 18:26:27.74

「Linux」、バージョン6.1でRustを導入へ--トーバルス氏が明言
https://japan.zdnet.com/article/35193491/

**デフォルトの名無しさん** · 2022/09/20(火) 20:25:26.21

>>752
いいね
ここ最近で一番いい知らせだわ

**デフォルトの名無しさん** · 2022/09/20(火) 20:46:56.46

今のところデバドラだけという話だけど
基幹部分の新実装をRustで作りましたという
人が絶対現れるからそのときどうなるだろ

**デフォルトの名無しさん** · 2022/09/20(火) 20:51:48.09

誰もvoldemort typeの名を呼ぼうとしない

**デフォルトの名無しさん** · 2022/09/22(木) 02:33:16.78

MS AzureのCTOが「新しいプロジェクトでC/C++使うのはやめて
非GC言語が必要な状況ではRustを使うべき時だ」ってツイートしてるけど
Visual StudioでもRustが最初からパッケージングされてるようになるのかな

**デフォルトの名無しさん** · 2022/09/22(木) 09:05:24.01

https://www.publickey1.jp/blog/22/cloudflarenginxrusthttppingoracdncpu31.html
Cloudflare、NGINXに代えて自社開発のRust製HTTPプロキシ「Pingora」をグローバルCDNに採用。性能向上しつつCPUとメモリ消費を3分の1に

**デフォルトの名無しさん** · 2022/09/22(木) 13:36:58.59

>>756
MSがRustの開発環境に投資するならVSCodeのエクステンションじゃない?
いまさらVSに対応言語を追加する気はないでしょ
どう考えてもWindowsユーザーは少ないだろうし

**デフォルトの名無しさん** · 2022/09/22(木) 19:38:28.16

>>756
マーク・ルシノビッチ氏、Microsoft AzureのCTOなのか。
インサイドWindowsにはお世話になったわ。

**デフォルトの名無しさん** · 2022/09/23(金) 05:18:56.24

Iteratorに対するIntoIteratorのように
Futureに対するIntoFutureということか
しかも.awaitに対して自動適用だからもっと効果が大きいか
非同期を返すビルダーに対してFutureを返させるためのビルド完了指示メソッド呼び出しが不要となる

**デフォルトの名無しさん** · 2022/09/23(金) 08:24:08.00

Rust analyzerが優秀過ぎてMSが入る余地なさそう
PythonがMS Storeから落とせるみたいにインストールが楽になるとかならありそう
VSに導入されたらそれはそれで面白いんだけど.Net言語との連携が強化されないと旨味がないな

**デフォルトの名無しさん** · 2022/09/23(金) 08:29:43.60

Rustからから.Net?
意味ないやろ...

**デフォルトの名無しさん** · 2022/09/23(金) 10:08:58.99

既存ライブラリがそのまま呼べるならお試しで部分的に新言語導入してみようとなる可能性もあるので意味はある

**デフォルトの名無しさん** · 2022/09/23(金) 10:43:28.96

Rust/Cliとか余計なもの作られそう

**デフォルトの名無しさん** · 2022/09/23(金) 12:31:56.94

>>758
VSCodeの方が対応は早いかもだが、VSに追加する気がないことは無いんじゃないかな

**デフォルトの名無しさん** · 2022/09/23(金) 17:48:32.43

>>762
書き方悪かったわ
Rustで作った何かをC#とかから簡単に呼べるといいねって意味だった

GoのCGoみたいな仕様だったら色んな意味で面白いと思う

**デフォルトの名無しさん** · 2022/09/23(金) 18:02:01.54

rust_analyzerの話題ついでに教えて欲しいのですが、保存なしで構文チェック等してくれるようにならないものなのですか？
編集を破棄して保存前の状態にしたい時があるので、できれば自動で保存したくないのです
Vim系プラグイン等を入れていれば無限に戻せるのかもしれないものの、Vimが使えない身としては困ってしまいます

**デフォルトの名無しさん** · 2022/09/23(金) 18:02:58.63

>>766
ああそれならありだな
まあ今でもC/C++とかで作ったdllなりをC#から呼び出せるから同じような感じでできるんじゃないかな

**デフォルトの名無しさん** · 2022/09/23(金) 18:04:41.93

>>767
まあ普通はGitを使うからね

**デフォルトの名無しさん** · 2022/09/23(金) 18:05:33.15

C#も.Netも全く興味ないので知らないが
PythonでもJavaScriptでも何でもRustで作ったライブラリなどを簡単に呼び出すことができる仕組みがそれぞれ整えられている
既存のものの置き換えは無意味だが新たに作られるものはRustで書くことが増えている

**デフォルトの名無しさん** · 2022/09/23(金) 21:26:00.89

repr(C)でCのフリしたRustじゃなくて、俺はありのままのRustが動いている世界線が見たいよ

**デフォルトの名無しさん** · 2022/09/23(金) 21:26:44.38

>>769
でも、破棄ならコミット後の状態にも戻せるぜ？

**デフォルトの名無しさん** · 2022/09/23(金) 21:42:44.57

>>771
ABI安定化するまではFFIでextern "C"は避けられないよ

**デフォルトの名無しさん** · 2022/09/23(金) 21:53:19.36

>>773
そんなことすべきでない
自由にRust コンパイラによる最適化の余地を与える現在の方針がベスト
外部に公開しなきゃいけない時に外部に公開する部分だけを#[repr(C)]や#[wasm_bindgen]など指定すればよい

**デフォルトの名無しさん** · 2022/09/23(金) 23:40:33.31

双方でマーシャル/アンマーシャルが必要になって無駄だよね

**デフォルトの名無しさん** · 2022/09/23(金) 23:55:09.24

なるほど

**デフォルトの名無しさん** · 2022/09/23(金) 23:58:10.15

対C/C++はそこまで必要ならそこもRustで書いちゃうから何ら問題はない
他の言語ではそれぞれもっと大きなオーバヘッドを持っているので誤差に収まり問題にならない

**デフォルトの名無しさん** · 2022/09/24(土) 00:06:07.91

やっぱエアプの複オジはわかってないなぁ

**デフォルトの名無しさん** · 2022/09/24(土) 00:11:50.36

>>774
pubなitemのABIに最適化関係ある？
なんかと混同してない？

**デフォルトの名無しさん** · 2022/09/24(土) 00:14:18.76

もしかして repr(Rust) のこと言ってる？

**デフォルトの名無しさん** · 2022/09/24(土) 03:05:40.90

Rustだけで閉じていればpubであっても自由に最適化されるからpubかどうかは関係ないでしょう
結局Rustの外に公開する部分だけの話に限られるからそこだけ相手毎に応じる現行の方式のままで構わないでしょう

**デフォルトの名無しさん** · 2022/09/24(土) 08:50:49.84

C++やRustはABI決まってないのにC言語は何故ほぼ決まってるの？

**デフォルトの名無しさん** · 2022/09/24(土) 09:11:44.18

>>781
dylibの場合pubは大いに関係あるよ

**デフォルトの名無しさん** · 2022/09/24(土) 09:15:16.80

ぶっちゃけあらゆるOSがC言語で書かれているあたりCの呪縛から逃れられないよ

**デフォルトの名無しさん** · 2022/09/24(土) 09:26:53.29

>>782
名前をプログラマが決められるからだよ

**デフォルトの名無しさん** · 2022/09/24(土) 09:44:37.12

>>782
むしろCは決まってるの？
決まってるわけじゃなくて単純だし歴史も長いから結果的にほぼ変わらない&その現状に合わせて変わらない変更をしてるだけみたいなことをgccかなんかの中の人の記事で読んだ気がするんだけどデマなんかな

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/24(土) 10:38:04.73

近年になって作られた高速リンカ mold の作者の話でも、
文書化されていない暗黙の仕様に何度もぶつかったみたいなことだったはず。

C 以外の言語 (処理系) もツールチェインは共通のものを使っている場合は結構あるし
どれがどの挙動に依存しているかようわからんので安易に整理するわけにもいかず、
結局のところは C コンパイラとは長年に渡って協調してきたから細かい問題点が
解決されているというだけで、そんなにカッチリした仕様が確立しているわけではないと思う。

**デフォルトの名無しさん** · 2022/09/24(土) 11:00:33.46

CはCPUベンダーが呼び出し規約を文書化してるよ
moldの話はELFやリンクに関連する話では
確かにABIのうちではあるけど言語ごとに異なる仕様になるようなものではないと思う

**デフォルトの名無しさん** · 2022/09/24(土) 11:33:36.58

AMD64の呼び出し規約をググるだけで2種類くらい出てくるのにコイツは何を言っているんだ？

>>786
呼び出し規約どころか構造体のレイアウトすら実装依存の部分があるよ

**デフォルトの名無しさん** · 2022/09/24(土) 13:14:15.81

>>789
そこでいう実装依存ってプラットフォームごとの差違のこと？
それとも同じプラットフォームでもツールチェイン依存でレイアウトが変わりうる場合があるの？

**デフォルトの名無しさん** · 2022/09/24(土) 14:25:21.27

cdeclとかstdcallみたいなやつ？

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/24(土) 16:06:51.67

>>791
その段階ではあまり曖昧さはない。
リンクする前の状態はリンクに必要な情報一式が入ってるはずなんだけど、
その扱いが言語や処理系をまたぐとややこしくなることもあるってこと。
アーキテクチャによって扱いを変える必要がある場合もあるし。

**デフォルトの名無しさん** · 2022/09/24(土) 16:24:43.84

>>792
コンパイラがリンカに渡す情報って統一規格があるの？

**デフォルトの名無しさん** · 2022/09/24(土) 17:05:25.99

>>793
別に統一されちゃいないがELFとかPEとか

**デフォルトの名無しさん** · 2022/09/24(土) 17:10:20.79

じゃあ、そのオブジェクト・ファイル形式の仕様に問題があるってことでは？

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/24(土) 17:36:26.33

>>795
ELF に置き換わるときにオブジェクトファイルの仕様の曖昧さはほとんど解消されていると思う。
ただ現実には全てが正しく実装されているわけではなく、
場合によっては正しかったほうを間違った側にあわさざるを得ないとかいう場合もある。
仕様がどうこう言ったって、実装が間違っていたって現実にもう動いているものがあるのなら変えられんのよ。
そういう歴史的負債がどんどん積み重なってわけわからんようになる。

**デフォルトの名無しさん** · 2022/09/24(土) 19:08:36.35

ARMの規約
https://github.com/ARM-software/abi-aa

**デフォルトの名無しさん** · 2022/09/24(土) 22:13:22.85

元々の他言語からrust呼び出す話ならそのレベルの話は関係ないでしょ
LLVMがよしなにやってくれるのでは

**デフォルトの名無しさん** · 2022/09/24(土) 22:29:32.09

ARM64ほどの絶対的パワーは必要ないので、ARM63で価格が120円くらいのチップになりませんかね？

**デフォルトの名無しさん** · 2022/09/25(日) 08:24:33.85

Option<NoneZeroUsize>などを使えば
IDやカウンタなどの用途でOption<usize>などを使っていたものを
半分のメモリサイズで済むようになるの？

**デフォルトの名無しさん** · 2022/09/25(日) 11:42:14.43

>>799
任せてください。符号ビット省略しておきますね

**デフォルトの名無しさん** · 2022/09/25(日) 15:32:52.52

Microsoftがやりそうなことだけど、Rustに独自拡張を含めたりとかしてほしくない

**デフォルトの名無しさん** · 2022/09/25(日) 17:24:00.83

Linuxはカーネル開発の為に今まさにRustに独自拡張を含ませようとしてるのに
Microsoftはダメなの？

**デフォルトの名無しさん** · 2022/09/25(日) 17:34:47.30

try_new()とかtry_reserve()とか元々ないのが不思議だったし導入の良いきっかけとなっただけ

**デフォルトの名無しさん** · 2022/09/25(日) 17:57:47.12

言語自体forkして独自のエコシステムを構築しようとしなければ別に良いのでは

**デフォルトの名無しさん** · 2022/09/25(日) 18:09:02.84

正直LinuxにRustなんて辞めればいいのに・・・

**デフォルトの名無しさん** · 2022/09/25(日) 18:14:08.03

Rustに限った話じゃないんだけどそれなりに複雑なロジック(例えばデコーダやパーサ)の実践的なテストの
作り方の解説とかどっかにある？例えばJPEGやPNG、MP3、AVIとかを扱うようなコードを想定
関数単体のテストはともかく、結合した状態で全てのコードを動かそうとすると入力パターンがどんどん増えるし
パディングビットにゴミがあっても問題ないかなどを考慮しだすと更に膨れあがる
さらに歴史が長いフォーマットだと、そもそも仕様をどう定義するのかという点が問題になることもあるし

**デフォルトの名無しさん** · 2022/09/25(日) 18:21:16.44

テストがすごいのはSQLite

**デフォルトの名無しさん** · 2022/09/25(日) 19:04:38.98

>>803
別に独自拡張とか入れてないだろ
コンパイラへの機能追加は全部本体に入れていてnightlyで使える状態だし
Linuxカーネル向けのallocなんかは単にライブラリであって言語自体がforkしてるわけではない

**デフォルトの名無しさん** · 2022/09/25(日) 19:57:21.62

>>806
なんかまずいことでもあるの？

**デフォルトの名無しさん** · 2022/09/25(日) 19:59:47.96

>>810
迷走と凋落、そして黒歴史化。

**デフォルトの名無しさん** · 2022/09/25(日) 20:07:26.82

>>807
メディアのエンコーディングのことはさっぱりしらんけど、一般的には結合テストじゃなくて、単体テストでパターンは網羅すべし
できるんならやればいいけど、結合テストで入力の網羅なんて普通はやらない

**デフォルトの名無しさん** · 2022/09/25(日) 20:26:59.51

>>812
条件分岐で関数Aを呼ぶべき所を間違えてA'を呼んでいて出力結果がちょっと変・・・というのをさっきやらかした
関数そのものに問題はないし処理内容がちょっと違うだけなので実行は出来てしまうのがいやらしい
で、テストを作ろうとしたけどどうしようか悩み中

**デフォルトの名無しさん** · 2022/09/25(日) 20:37:27.14

そういうのは呼び出し側の単体でええんちゃうの

**デフォルトの名無しさん** · 2022/09/25(日) 21:09:49.29

>>807
歴史があり、曖昧さが残るフォーマットの再実装はできればやりたくない仕事だな。
対応する仕様を現代で最低限必要なものを取捨選択して決め打ちで実装しつつ、考慮漏れでクリティカルなものは取り入れていく方式でやるしかないよ。

歴史あるフォーマットの曖昧な対応を追体験する作業は、不毛だからできれば既存実装におまかせすべき。

**デフォルトの名無しさん** · 2022/09/25(日) 21:31:04.61

>>814
中間コンポーネントの単体テストって普通どうやるんだろ
後段のコンポーネントを切り離してテストするのか？繋げたままテストするのか？
切り離せるようにするとその部分にバグが入り込む余地が生まれるし

>>815
歴史が長いと仕様上○○であるがこれに準拠しないアプリやデータが少なからず存在するため
△△のような実装がベターだみたいなのが沢山あるからねぇ
そしてこの手の情報はググっても網羅するのが難しい

**デフォルトの名無しさん** · 2022/09/25(日) 21:51:09.44

>>811
Linux側にメリットがないと言ってる？

**デフォルトの名無しさん** · 2022/09/25(日) 21:51:47.84

>>816
> 中間コンポーネントの単体テストって普通どうやるんだろ
中間の意味がよく分からんけど>>813みたいな話なら関数A、関数A'をモックにしてテストする
たいていのテストツールではモックの呼び出し回数のテストができる

**デフォルトの名無しさん** · 2022/09/25(日) 21:53:52.45

>>816
JavaみたいにDIが発展しているタイプの言語だと中間コンポーネントが呼び出すコンポーネントはモックをインジェクトしてやって、適切なメソッドが呼び出されたかのテストとかよく書くね。

けど、正直Rustを含む他の言語で中間のレイヤだけ独立してテスト書くようなこだわりはあまり見たことも書いたこともないなぁ。
モジュール設計の考え方が変わるからかな？

**デフォルトの名無しさん** · 2022/09/25(日) 22:41:02.05

今作っているのだとこんな感じかな？
関数C(データの前処理、処理単位への分割)
↓
関数B(処理全体の制御)→関数A'(処理1-2)
↓
関数A(処理1-1)

>>818,819
その場合モックへ切り替える機構はどうするんだろ
そのためにコードを書き換えていてはミスが入り込む可能性が高くなるし、条件付きコンパイルも同様のリスクがある

てかThe Rustのテストの所を見ても関数の呼び出し状況をテストする方法とかは書いていないんだよな
なんかその辺を良い感じに可視化してくれるツールとかあるんだろうか

**デフォルトの名無しさん** · 2022/09/26(月) 00:07:36.94

>>820
すまん rust だと cargo test で単体テストを実施するみたいだけど mook/stub をどうやって使うかはよくわからんかったわ
C++ とかだと googlemook とか使ってテスト用のモッククラスを作って入れ替えるかたちだね

**デフォルトの名無しさん** · 2022/09/26(月) 00:33:03.55

mockall使うとか

**デフォルトの名無しさん** · 2022/09/26(月) 06:28:19.26

cargo testで関数テスト、モジュールテスト、モジュール間テストなどあらゆるテストをやっているけどダメなの？

**デフォルトの名無しさん** · 2022/09/26(月) 06:47:39.41

>>823
>>820 > その場合モックへ切り替える機構はどうするんだろ
に答えてやってくれ

**デフォルトの名無しさん** · 2022/09/26(月) 19:21:24.42

モックやスタブは別モジュール化しておいて
mod tests内では本物モジュールをuseする代わりにそれをuseするだけじゃないの？

**デフォルトの名無しさん** · 2022/09/26(月) 19:31:47.69

あと#[cfg(test)]でそれをuse
そして#[cfg(not(test))]で本物use

**デフォルトの名無しさん** · 2022/09/26(月) 19:31:51.25

他の言語でもユーティリティを使わずに、DIやモックを自分でやったことがないんだろうな
説明が面倒だ

**デフォルトの名無しさん** · 2022/09/26(月) 19:38:20.09

>>827
テスト以外の開発の話でも
フレームワークに依存してやってる人は
単純なこと含めて本質的なことを理解してない人が多く
フレームワークなしでは何も分からず何も出来なくなってしまう例を時々見かける

**デフォルトの名無しさん** · 2022/09/26(月) 21:10:39.16

cfg使えば良いじゃないって人は#ifまみれで一見しただけじゃ
何がどう動くんだか判らないCのコードを正当化するつもりなのだろうか
Rustは人間が注意すれば問題ないみたいな考えはレガシーで時代遅れだ
という思想の言語だと思っているんだが違うのかな

**デフォルトの名無しさん** · 2022/09/26(月) 21:41:35.64

>>829
#ifは使わないし
cfg(test)はテスト分離のため必須でしょ
どんな環境でも魔法は無いよ

**デフォルトの名無しさん** · 2022/09/26(月) 23:33:07.51

>>829
cfg使わないで済むいい方法があるなら書いてよ...

**デフォルトの名無しさん** · 2022/09/27(火) 01:17:35.37

mod tests に cfg(test) は必要だとして
依存性の注入にはtrait使えって事なのでは

**デフォルトの名無しさん** · 2022/09/27(火) 07:51:04.95

traitで置き換え可能にするのが面倒というのはありそうだな。

**デフォルトの名無しさん** · 2022/09/27(火) 08:15:53.87

AMD64のデフォルトのオペランドサイズは32bitなのにusizeが64bitなのは何でなのかな

**デフォルトの名無しさん** · 2022/09/27(火) 11:05:22.42

size_tが64bitだからでは

**はちみつ餃子** ◆8X2XSCHEME · 2022/09/27(火) 12:28:55.13

>>834
usize はポインタのサイズということになっている。

**デフォルトの名無しさん** · 2022/09/27(火) 19:04:38.56

>>831
単体テストで、依存を分離するのは当然のことすぎてみんな説明が億劫になってる
C++だろうがRubyだろうが、モックやスタブを使って、関数同士やクラス同士の依存を切り分けてテストするのは当たり前
そうしないとそもそも単体テストにならないじゃん

わかってる人にしかわからないであろう簡略な説明をすると、テスト用のエントリポイントで、テストに使うモックオブジェクトを指定するだけだよ
そういうことができるようにあらかじめコード設計しておかないといけないがな
考えてなかったならリファクタが必要

**デフォルトの名無しさん** · 2022/09/27(火) 19:48:22.41

そんなフワフワした説明されても...

**デフォルトの名無しさん** · 2022/09/27(火) 19:51:56.44

本物と異なり決まった値を返す送信元スタブと
本物と異なりassertだけする送信先モックを
mod testsの中では本物の代わりにuseするだけだよね
入れ替えちゃうからtrait制約で本物も偽物も受け付け対応とかわざわざする必要ないよね

**デフォルトの名無しさん** · 2022/09/28(水) 00:44:24.76

>>839
useしたモックをどうやって注入すんの
関数の引数もstatic変数でも良いけど、テスト対象の実装がモックも本物も選択的に使えるようにするならば、
genericな型を受け付けるような実装にしておかないといけないのでtraitが登場するのでは

それともmod testsの外もcfgで置き換えると言っている？

**デフォルトの名無しさん** · 2022/09/28(水) 00:48:00.37

要は
use imp::Foo;
fn target(foo: Foo) {}
がテスト対象だとして
mod tests {
use mock::Foo;
#[test]
fn test() {
target(Foo::new());
}
}
してもコンパイル通らないよね
targetがimp::Fooもmock::Fooも受け付けるようにするにはtraitが必要では