Rust part24

[表示 : 全て最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 1001- 2ch.scのread.cgiへ]
Update time : 02/27 05:30 / Filesize : 305 KB / Number-of Response : 1022
[このスレッドの書き込みを削除する]
[＋板最近立ったスレ＆熱いスレ一覧 : ＋板最近立ったスレ／記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

Rust part24

1 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:41:26.82 ID:T4AFD1f4.net]: 公式
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 part23
https://mevius.5ch.net/test/read.cgi/tech/1708677472/
2 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:42:29.23 ID:T4AFD1f4.net]: 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/
3 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 06:43:12.56 ID:T4AFD1f4.net]: 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
4 名前：/ 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/ []: [ここ壊れてます]
5 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 08:12:23.89 ID:8cya6pTK.net]: Cloudflare、HTTPプロキシ開発用RustフレームワークPingoraをオープンソース化
ttps://www.infoq.com/jp/news/2024/03/cloudflare-open-sources-pingora/
6 名前：デフォルトの名無しさん [2024/05/27(月) 19:41:54.75 ID:SG55qLTi.net]: >>1 乙
7 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 21:05:50.42 ID:DNPKhjhD.net]: なんで黙ってﾜｯﾁｮｲスレのリンク消したの？
8 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 21:10:59.53 ID:uDjd5cKa.net]: >>1乙ust
9 名前：デフォルトの名無しさん mailto:sage [2024/05/27(月) 23:31:45.00 ID:NihCR1ik.net]: rust-lldって魔法？
10 名前：デフォルトの名無しさん mailto:sage [2024/05/28(火) 23:01:09.87 ID:r9uY5dzk.net]: 「Sudo for Windows」はRustで開発されている！
メモリ安全が重視される分野で採用が広がるRust言語
ttps://forest.watch.impress.co.jp/docs/serial/yajiuma/1594981.html
次期大型更新「Windows 11 バージョン 24H2」に
搭載されることが確定した「Sudo for Windows」が、
Rust言語で開発されていることがわかった。
11 名前：デフォルトの名無しさん mailto:sage [2024/05/29(水) 09:39:32.15 ID:YfGaww9I.net]: 完全にRustは残る言語になってしまったね
12 名前：デフォルトの名無しさん mailto:sage [2024/05/29(水) 11:05:17.42 ID:frLAIx0l.net]: 言語の生き残るか否かもWindows次第かな
13 名前：デフォルトの名無しさん [2024/05/29(水) 13:45:30.43 ID:6x6vV3tF.net]: この言語を支持してるやつは総じてデバッグ能力が低い
14 名前：デフォルトの名無しさん mailto:sage [2024/05/29(水) 13:56:47.79 ID:HitYRPv5.net]: なるほどそれはもうやるしかないね
15 名前：デフォルトの名無しさん [2024/05/29(水) 14:07:58.08 ID:377og/WO.net]: 今更こんなのだけで一喜一憂するの？

ちなみにAzureCLIもRustだぞ
MacでHomebrewでインスコする時にRustのコンパイル始まって凄く時間掛かる
16 名前：デフォルトの名無しさん mailto:sage [2024/05/29(水) 14:55:30.35 ID:0Pyy6QQw.net]: ʕ◔ϖ◔ʔ
17 名前：デフォルトの名無しさん mailto:sage [2024/05/29(水) 16:53:17.15 ID:bMu5OGl6.net]: >>12
テスト走らせるんじゃあかんの？
18 名前：デフォルトの名無しさん [2024/05/29(水) 17:06:12.76 ID:643EHPjo.net]: >>9
これ仕組み上、console APIやTUIは動作しない
(それと肝心なところのほとんどがunsafeなのは見なかったことに)
19 名前：デフォルトの名無しさん mailto:sage [2024/05/29(水) 19:19:21.66 ID:AbIsIlhD.net]: そういや、sudoとかの引数のバッファオーバーフローとかって、std::env::args_os使っていれば安全なのかな？
20 名前：デフォルトの名無しさん mailto:sage [2024/05/29(水) 22:46:32.28 ID:b7HyT2Iv.net]: unsafeはRust外のFFI/API境界でのやむを得ない出現か
unsafeを使うことで効率的かつ安全なパターンになる時のいすれかだが
後者のパターンは特定のプログラムから切り離してsafeなインターフェースを提供する汎用ライブラリに閉じ込めるのが好ましく
標準ライブラリはそのようにして出来ている
21 名前：デフォルトの名無しさん mailto:sage [2024/05/30(木) 12:31:47.54 ID:D8KcVhgB.net]: つまりwindowsクレートはsafe interfaceの提供をサボってるということ？
22 名前：デフォルトの名無しさん mailto:sage [2024/05/30(木) 12:33:13.48 ID:VdmPCECN.net]: Rustと外側との境界はunsafeにせざるを得ないのは当たり前なのに肝心なところはunsafeと言われてもなぁ。
レビューすべき箇所が局所化されるだけでも十分なメリットだろ。
23 名前：デフォルトの名無しさん mailto:sage [2024/05/30(木) 14:46:49.26 ID:YCUWE+u3.net]: >>20
>>21
どちらも正しい
Rustとその外側の境界部分で必ずunsafeが生じるからそこを問題にすることはない
ただしその部分は安全なインタフェースを提供するモジュールかできればクレートとして分離するのが好ましい
24 名前：デフォルトの名無しさん mailto:sage [2024/05/30(木) 16:38:16.78 ID:YSwCBZpR.net]: Rust製Webサーバーで一番使われてるフレームワークって何だろ
MySQLと親和性高いなら使ってみたい
25 名前：デフォルトの名無しさん mailto:sage [2024/05/30(木) 18:56:43.74 ID:d8P/nzpp.net]: >>23
axumとsqlx
26 名前：デフォルトの名無しさん mailto:sage [2024/05/30(木) 21:16:17.01 ID:YSwCBZpR.net]: >>24
ありがと、試してみよう
27 名前：デフォルトの名無しさん mailto:sage [2024/05/31(金) 21:36:08.12 ID:PEZeXgnU.net]: コンパイル前にcargo sqlx prepareでDBサーバからデータの型を得ておくことで静的型チェックできる仕組みなんだね
28 名前：デフォルトの名無しさん mailto:sage [2024/06/01(土) 10:39:11.44 ID:8vnvDrFp.net]: へー、便利そう。
だけどこういう仕組みってカラム追加時のDBのマイグレーション辺りが入ってくるととたんに難しくなるんだよなぁ。
29 名前：デフォルトの名無しさん mailto:sage [2024/06/01(土) 22:15:15.67 ID:hl1xX5EU.net]: >>27
そういうDBテーブル構成変更するとどんなプログラミング言語でも何らかの対応が必要となるよ
Rustでsqlx利用ならばDB構成変更した時にcargo sqlx prepareで型をDBから入手し直せばコンパイル時に静的に型チェックされるから楽で安全だね
30 名前：デフォルトの名無しさん mailto:sage [2024/06/01(土) 22:32:36.24 ID:M7bbwRO6.net]: DBの構成管理をどこで行うかという話
その辺の道具類は他言語に比べてRustはまだまだなので
DB側のツールで管理しておくという昔ながらのやり方が現状のベスト
31 名前：デフォルトの名無しさん mailto:sage [2024/06/01(土) 22:35:04.27 ID:25uf1xqx.net]: スクラッチのPHPみたいにSQL直書きからのexecuteはナシ？
32 名前：デフォルトの名無しさん mailto:sage [2024/06/01(土) 22:44:45.41 ID:azEYwwHp.net]: >>30
Rustのコード内にSQL直書き文字列を書ける
その上でデータベースとの静的な型チェックもされるのがsqlxのメリット
33 名前： 警備員[Lv.6][新芽] mailto:sage釣 [2024/06/01(土) 22:51:53.44 ID:l8IWJadP.net]: それで実行計画も取れるの？
34 名前：デフォルトの名無しさん mailto:sage [2024/06/01(土) 23:58:30.16 ID:K7NGQLE/.net]: 実行計画はDBのデータではないから型チェックは意味ないような
35 名前：デフォルトの名無しさん mailto:sage [2024/06/02(日) 09:14:40.51 ID:plnJaR5e.net]: >>21
機械語に近い部分がunsafeなのは当たり前だけど
それを手書きしていることを納得させるのが難しいんだろう
一番自動化されてるフレームワークを使ってみたいんだろ
36 名前：デフォルトの名無しさん mailto:sage [2024/06/02(日) 12:55:11.71 ID:vGgRDkgp.net]: 接続相手の仕様が形式化されたデータとして存在すれば
Rust 上の関数との対応付けを自動化できることもあると思うけど
形式化されたデータは誰かが準備しないといけないことには変わりないからなぁ。

Windows では API の仕様記述を WinMD と呼ばれる形で標準化してるけど
それだって WinRT (ちょっと高級な API) が前提になっているのでそんなに万能ではない。

あらゆる仕様を記述できるほど自由度 (複雑さ) のあるフォーマットにしたら結局は
プログラムを書くのとそんなに変わらんようになるので自動化できる部分は自動化して
ややこしい場合は手書きするという割り切りしないと仕方ない。
37 名前：デフォルトの名無しさん mailto:sage [2024/06/02(日) 23:32:50.95 ID:JYjUVuWd.net]: Unix系システムコールとの共通部分は
ファイルシステムなど標準ライブラリとして安全なインターフェイスを提供できてるね
Windows特有部分も同じようにMicrosoftがsafeなライブラリを公式に用意することが望ましいのかな
38 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 08:58:28.03 ID:DC3aHaSn.net]: >>35,36
なるほど。結構時間経ったと思うが厳しい。

Microsoftがsafeなライブラリを公式に用意するまで、
プロダクションでのRust採用は様子見するのが良さそうだ。

Linux特有の機能が必要な場合も同様に様子見するのが良さそうだ。
39 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 09:53:26.77 ID:oYPTQzXH.net]: >>37
Windows クレートはもうかなり充実してるよ。
メタデータからの自動生成なので網羅的だし、 safe でいけるメソッドは safe になってる。
unsafe なのは本質的に unsafe なのでどうしようもないし。

Readme に書いてある例が古い Win32 API を使うスタイルの書き方だから印象が悪いのかなぁ……。
40 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 12:15:09.36 ID:xZhYxepu.net]: >>37
LinuxでRustで困ってることないよ
様子見しなきゃいけないことがあるのならば具体的に挙げてみたら？
41 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 15:47:20.28 ID:8wxJn/St.net]: >>38
>本質的に unsafe
良いキーワード出た、深掘りしてくれ

これとか
github.com/tokio-rs/io-uring

io_uringが本質的にunsafeだとでも思ってるのかな？
42 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 16:27:42.41 ID:PBVPy7rj.net]: 本質的にC++な機能といえば多重継承
多重継承は他の言語に移植できない
万一できたとしたらそれは自動生成ではなく手作業で工夫されたコードだろうね
43 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 17:17:59.54 ID:/dTVE8NF.net]: Win32APIを素で提供しようと思ったらunsafeなのは仕方ないので、もう一枚ハイレベルなラッパーかませてsafeにしてほしいところではある。
44 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 19:27:13.29 ID:oYPTQzXH.net]: だからモダンな WinRT に移行しようね！
45 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 20:11:34.31 ID:/dTVE8NF.net]: WinRTってWin32のAPI網羅できてるの？
モダンなAPIが古いのを機能的に網羅できてないから仕方なく使ってる気持ちなんだけど。
46 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 20:49:12.70 ID:oYPTQzXH.net]: WinRT は「おおよそ」には Win32 API の機能を網羅しているが
根本的なパラダイムが違っていて単純には置き換えられない場合はある。
最初から WinRT を前提として作っていれば Win32 API 抜きで行けることは多いよ。
ゼロではないところがイライラするかもしれんけど。
47 名前：デフォルトの名無しさん mailto:sage [2024/06/03(月) 21:57:04.03 ID:7I637fUw.net]: >>41
クラス多重継承は問題多すぎなダメな機能なので多くの言語で禁止している
クラス継承そのものが問題を多く抱えているため各機能のインターフェースなどを実装するのが望ましい
Rustならば複数のトレイト境界を指定することでそれら複数のトレイト機能を実装した任意の型を対象に抽象的なプログラミングができる
48 名前：デフォルトの名無しさん [2024/06/04(火) 07:49:08.27 ID:YQQ4Gdo/.net]: かきを最新AIに重箱の隅をつつく用意尋ねましょう
全ての電磁波は強い低周波も高周波も被爆する?
電磁かいが強い場所は20Hzと55Hzは磁気閃光これも被爆している.?
音波も強い場合は被爆する?
※自然界の化学科学の観測結果論文と人間の人工物で可能な化学と科学論文を読み込ませておく
是者と校舎を別々で回答する用意する
さらに制度を挙げるなら
グレーゾーンの論文をできるともいえるしできないともいえる用意認識させる

現在の科学が正しいのならなら電磁波攻撃はこのグレーゾーンの論文を使用しているので逃亡できている?

統合失調症電磁は音波なら周囲の者被爆している!?
寿命が短いのと免疫力低下起きて当然
49 名前：デフォルトの名無しさん [2024/06/04(火) 20:02:17.33 ID:JvLx0o4/.net]: GPT4-Vの100分の1のサイズで同等の性能を誇るマルチモーダルモデル「Llama 3-V」が登場、トレーニング費用はたった8万円
2024年05月29日 14時00分
OpenAIがサム・アルトマンCEOを含む「安全・セキュリティ委員会」を設置、さらにGPT-4後継モデルのトレーニングを開始
2024年05月29日
「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
※対象者【被害者】そっくりの返答が可能
たった数秒の音声データから音声合成が可能な「VoiceCraft」
2024年04月16日 07時00分
OpenAIがわずか15秒の音声からクローン音声を生成できるAIモデル「Voice Engine」をリリース
2024年04月01日
会話相手を数秒見つめて声を登録するだけでその人の声だけを聞くことができるAIヘッドホンシステムが開発される
2024年05月30日
※対象者の声を個別に録音
50 名前：デフォルトの名無しさん mailto:sage [2024/06/04(火) 21:25:19.75 ID:iVGm+TdX.net]: std::ptr::addr_eqでdyn同士やdynと通常参照を比較してもいいんだよね
51 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 02:32:30.56 ID:asdywUyB.net]: 比較の方法が複数あるとして
最も優秀な方法に依存するのではなく抽象に依存するのが定石だよな
52 名前：デフォルトの名無しさん [2024/06/05(水) 13:57:39.45 ID:nZd9x5hF.net]: >>17
>肝心なところのほとんどがunsafe

当たり前やん
そもそも観なかったことにするための機能なんだし
53 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 14:16:34.14 ID:VxlYmTlG.net]: 言語のパラダイムでどれだけ頑張っても言語の外はその規則に従ってくれないよ。
そこらへんの境界線でおおよそどこでも信頼できるインターフェイスは ABI だけ。
根本の部分が C の影響下にある状況のほうは変えようがない。

一応 unsafe rust という選択肢が登場した分だけだいぶんマシになってんだよ。
54 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 14:19:53.54 ID:wo6YIDEn.net]: >>38,52
>本質的に unsafe

本質的にunsafeの定義、早う
55 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 14:28:05.14 ID:vQWinlMd.net]: C/C++のコード全体が常にunsafeすなわち自動的な安全保障なしなのに対して
Rustはsafe部分のコードが自動的に安全保障されるという明確な違いがある
56 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 14:33:58.97 ID:jddDZazx.net]: >>38,54

定義するとは何かすら知らないレベルでRustやってるのかよw
57 名前：デフォルトの名無しさん [2024/06/05(水) 15:41:52.55 ID:NMAS1RiM.net]: 定義するとは何かも知らなくても書けるのがRustの良いところ
58 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 18:13:30.31 ID:asdywUyB.net]: なぜ定義なんだ
喩え話では駄目な理由を考えるとすぐ思いつくのは、喩え話は非○○的だから駄目なんだよね
59 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 19:11:15.28 ID:ubKPmxXH.net]: >>49
dynはアドレスとvtableの対なので使える

use std::fmt::Display;
let i = 12345;
let r = &i;
let d: &dyn Display = &i;
// assert!(eq(r, d)); // 型が不一致でコンパイルエラー
assert!(addr_eq(r, d)); // アドレスが一致

文字列strはアドレスと長さの対なのでこのように比較できる

use std::ptr::{addr_eq, eq};
let s1 = "abcdef";
let s2 = &s1[..3];
let s3 = &s1[3..];
assert!(!eq(s1, s2)); // 長さが異なるので不一致
assert!(addr_eq(s1, s2)); // アドレスが一致
assert!(!addr_eq(s1, s3)); // アドレスが不一致

文字列をバイト列に読み替えたときにも使える

let b1 = s1.as_bytes();
// assert!(eq(s1, b1)); // 型が不一致でコンパイルエラー
assert!(addr_eq(s1, b1)); // アドレスが一致
60 名前：デフォルトの名無しさん mailto:sage [2024/06/05(水) 19:38:28.12 ID:VxlYmTlG.net]: >>53
safe にするのが不可能(少なくともそれ単体は)というシンプルな意味で使ってるつもりだが
61 名前：デフォルトの名無しさん mailto:sage [2024/06/06(木) 22:14:32.57 ID:Gs5l9pj8.net]: fn 単純にこの比較も<T>(slice: &[T], index: usize) {
　let p = &slice[index];
　let q = &slice[index..];
　// assert!(eq(p, q)); // 型不一致
　assert!(addr_eq(p, q));
}
62 名前：デフォルトの名無しさん [2024/06/07(金) 12:52:26.48 ID:tQZH7Tnk.net]: グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
https://ascii.jp/elem/000/004/202/4202481/
63 名前：デフォルトの名無しさん mailto:sage [2024/06/07(金) 23:50:20.38 ID:liF+4tB0.net]: as *const ()でupcastして比較しているだけなのか
64 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 04:40:43.01 ID:j2N7L69L.net]: Option<String>型のxがある時に
x.as_ref()とするとOption<&String>が得られ
x.as_deref()とするとOption<&str>が得られることがわかりました

Option<&String>型のyがある時に
y.as_deref()としてもOption<&String>のままになりました
yからOption<&str>を得るにはどうすればいいのでしょうか？
65 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 09:07:24.88 ID:Kcr3cAzI.net]: let tmp = Some(y.unwrap().clone());
let hoge = tmp.as_deref();
66 名前：デフォルトの名無しさん [2024/06/08(土) 09:09:50.82 ID:Kcr3cAzI.net]: cloneしたくなかったら
let hoge = Some(y.unwrap().as_str());
67 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 10:33:13.95 ID:9nPXIyFb.net]: unwrap()は基本的には使ってはいけない。

使ってもよい場合は論理的にNoneが絶対に来ないことが保証されてる場合で、
直前にNoneではないことをチェックしていて明白な場合と、
構造的にそこにNoneが来ないことをコメントで明記している場合のどちらか。
68 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 10:34:38.61 ID:9nPXIyFb.net]: もう一つは簡易プログラミングをする場合で、
そこにNoneが来た時に処理続行の意味がなく、
パニックという形でプログラムを終わらせても構わない場合。
これは本来はきちんとエラー処理対応するのが好ましい。
69 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 10:39:31.95 ID:9nPXIyFb.net]: ドキュメントのサンプルでは、
エラー処理は邪魔なので簡易的にunwrарが多用されているが、
それをそのまま用いるのがマズい理由は上述のため。
70 名前：デフォルトの名無しさん [2024/06/08(土) 10:45:50.57 ID:TRqvICLK.net]: 「毒杯飲む直前どんな気持ちだった？」ソクラテスと対話できるAIを開発！
2024.06.04
リコーと理研、技術の実用化の“兆し”を察知するアルゴリズムを開発
2024/06/05
グーグル、資料のわからないところを最新AIに質問できる「NotebookLM」日本版公開
2024年06月06日
71 名前：デフォルトの名無しさん [2024/06/08(土) 11:07:47.98 ID:Kcr3cAzI.net]: >構造的にそこにNoneが来ないことをコメントで明記している場合

これはexpectのことを言ってるのかな？
panic!することには変わりないが
72 名前： 警備員[Lv.1][新芽] mailto:sage釣 [2024/06/08(土) 11:13:56.61 ID:wxBkz9QQ.net]: truckに手をだす勇者はいないのか？
https://github.com/ricosjp/truck
73 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 11:35:42.10 ID:91vCCt9S.net]: >>63
y.map(|s| s.as_str())
or
y.map(String::as_str)
74 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 11:44:51.45 ID:91vCCt9S.net]: >>70
単にunwrapでpanicさせるんじゃなくて
unwrap_orやunwrap_or_elseなどを使ってfallback valueを返す

>構造的にそこにNoneが来ないことをコメントで明記している場合
個人的に↑これには賛同しかねる
コードが脆弱になるから
75 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 12:33:54.09 ID:JruRF9Uj.net]: 構造的にNoneでないことを期待しているロジックならチェックしたところでどうせリカバリできないんだし
単にパニックでいいと思うけどな
76 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 12:53:40.15 ID:dp0B2cJQ.net]: 事前条件・事後条件に反するときは panic するのが推奨されてなかったっけ？
要するにそういうことが一度でも起きたらバグが含まれているプログラムということだから修正するという前提がついてる。
あらゆるルートを想定するのも無意味だし、想定しないルートに入ったまま続けてもろくなもんじゃないので変なところがあったら止まったほうがいい。

ライブラリとして提供するなら expect にするに越したことは無いが
ただの panic でもスタックトレースは出せるし、
発見するのが自分 (またはチーム内などの身内) で修正するのも自分なら多少は雑でもよかろ。
77 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 13:02:44.03 ID:m8p9RP7E.net]: >>68
サンプルでrust unwrар好きだなと思っていたんだが、そんな理由で多用だったのか
78 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 13:06:19.28 ID:nAguSD5l.net]: パニックさせるということはNoneかどうかをチェックしているということ
そしてパニック用のコードもそこに含まれるということ
そのため高速化がシビアなケースではunwrap_unchecked()が使われている
unsafeなので確実な監視対象となる点でむしろ好ましいケースもありうる
とはいえ特殊な場合を除き非推奨です
79 名前：デフォルトの名無しさん mailto:sage [2024/06/08(土) 14:06:17.67 ID:dp0B2cJQ.net]: ロジック的に None でありえないことをコンパイラが見抜ける状況でなら最適化で余計なチェックが消えることもあるし、分岐予測で速度的ペナルティはどうでもよくなることもある。
チェックするにしたって単発ではナノ秒単位の処理なので速度的に足を引っ張ることはまずない。
動画処理とか機械学習とかいった計算量が大きいものならチューニングが必要になることはあるかもね。
80 名前：デフォルトの名無しさん mailto:sage [2024/06/09(日) 00:14:30.88 ID:FH5YvHUC.net]: 例えばここにある`self.front.as_mut().unwrap()`や`front.next_kv().ok().unwrap()`のunwrapの使い方は妥当？
https://github.com/rust-lang/rust/blob/master/library/alloc/src/collections/btree/navigate.rs#L79-L80
81 名前：デフォルトの名無しさん mailto:sage [2024/06/09(日) 00:37:45.34 ID:84HY0iaQ.net]: >>79
if self.is_empty() {
　None
} else {
　以降にあるから内部構造ロジックにより問題なし
82 名前：デフォルトの名無しさん mailto:sage [2024/06/09(日) 00:50:28.83 ID:84HY0iaQ.net]: でもmatch self.front.as_mut() {
　Some(x) => で書けるならunwrap無い方がいい
83 名前：デフォルトの名無しさん mailto:sage [2024/06/09(日) 01:03:57.65 ID:84HY0iaQ.net]: 例えば>>65ならば
match y {
　Some(s) => s.as_str(),
　None => None,
}

そのNone => Noneの時はmapに簡略できる
y.map(|s| s.as_str())

それをメソッド記法でなくフルに書くと
y.map(|s| String::as_str(s))

ここで|s| f(s)はfと簡略できるためこうなる
y.map(String::as_str)
84 名前：デフォルトの名無しさん [2024/06/09(日) 08:02:48.25 ID:GyoPGP3N.net]: 全ての波【電磁波】で下記の症状が起きる
理由は電磁波が強いために起こるか電磁波が通過すれば磁気が生じて鉄分が振動して間接的に鼓膜などが振動する
マイクロ波聴覚効果を用いた音声伝送に関する検討
2018/03/05
https://www.bookpark.ne.jp/cm/ieej/detail/IEEJ-ZT181039-PDF/
マイクロ波聴覚効果 Wikipedia
https://ja.wikipedia.org/wiki/%E3%83%9E%E3%82%A4%E3%82%AF%E3%83%AD%E6%B3%A2%E8%81%B4%E8%A6%9A%E5%8A%B9%E6%9E%9C
>>マイクロ波を照射された被験者は、クリック音やブザーのようなうなり音が聞こえる
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
https://news.mynavi.jp/techplus/article/20240604-2958879/
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
https://news.mynavi.jp/techplus/article/20240606-2960578/
※電磁波も振動させれると記載あり
最低でも下記ノ電磁波の威力が必要なら行っている者全員補足されている
GPSの電波は超微弱
https://gigazine.net/news/20240421-gypsum-gps-receiver/
［２２］米国特許５８６８１００号
【ＧＰＳ位置情報を使用した動物コントロール・システム】
一例ですが年々受信機の感度は向上している
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961238/
電磁波音波攻撃をされている部位ごとにホルモンや異常物質などの観測
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
https://www.asahi.com/articles/ASS652V7RS65ULBH00GM.html
85 名前：デフォルトの名無しさん mailto:sage [2024/06/09(日) 22:41:10.47 ID:YI6R90yo.net]: 今はOptionにas_slice()があるんだな
Some(x)なら[x]でNoneなら[]のスライス
アドレスは同じで長さが1か0なのか
86 名前：デフォルトの名無しさん [2024/06/10(月) 07:48:45.58 ID:QAB9rEB/.net]: AIの性能が上がれば世界情勢が見えてくる
にゅーーすで話していることもそれらしきことを話すようになる

まづボイス・トォ・スカルが存在している場合としていない場合を問う
そのあとに人間の行動をどのように行動するかを問う

交友関係全てわかる範囲で入力しておく
社会っ情勢を知るにはさらにどういった役職等も調べておく

自分が使用しているボイス・トォ・スカルを本物か偽物化も割り出せる
87 名前：デフォルトの名無しさん mailto:sage [2024/06/10(月) 12:58:47.18 ID:GcV83QCC.net]: >>80
本当に内部ロジック上問題がないのかを確認するために見る必要のある範囲が広すぎるのが問題

>>81
if self.is_empty()を生かしたままという意味なら
不変条件を満たしてないコードが埋もれるのが問題
if self.is_empty()を無くすという意味なら
コードで表現したい意図から乖離するのが問題
88 名前：デフォルトの名無しさん [2024/06/10(月) 13:47:20.88 ID:QAB9rEB/.net]: 不眠症にカップ麺やスナック菓子などの「超加工食品」が関係しているという研究結果
https://gigazine.net/news/20240610-insomnia-linked-ultra-processed-foods/

インターネットの都市伝説「The Backrooms」の起源となった画像の正体はどうやって判明したのか？
https://gigazine.net/news/20240610-origin-of-the-backrooms/

GoogleのGeminiとMicrosoftのCopilotが過去のアメリカの大統領選挙を含めた世界中の選挙の結果を正常に返していないことが判明
https://gigazine.net/news/20240610-google-microsoft-chatbots-election-questions/
89 名前：デフォルトの名無しさん [2024/06/10(月) 20:09:22.20 ID:QAB9rEB/.net]: ボイス・トォ・スカル
電磁波音波攻撃が判明する
人間は電磁界を発生させている
※被害者の身体に痕跡あり
パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
名市大、頭蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
早大、物質中の創発磁気モノポールに起こる集団振動現象を理論的に発見
2024/06/04
理研、電子ビームの電子回折をアト秒で制御できる技術を開発
2024/06/06
分子研など、金ナノ粒子が円偏光の左右選択性を70倍に高めることを発見
2024/06/06
弾性乱流と古典的なニュートン乱流との共通点を発見――弾性乱流を記述する数学的理論の開発に寄与　OISTら
2024-5-29
京大、テラヘルツ波の照射で超伝導体の臨界電流を制御できることを実証
2024/05/28
産総研など、1000個以上の量子ビットを制御可能な超伝導回路の原理実証に成功
2024/06/05
名大など、水素原子の約1/20の超高精度で収差補正できるX線顕微鏡を開発
2024/05/09
90 名前：デフォルトの名無しさん [2024/06/10(月) 20:09:43.09 ID:QAB9rEB/.net]: 細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発阪大など
2024/05/07
OIST、有機電気化学トランジスタのON時に生じるタイムラグの原因を解明
2024/05/07
並行世界でタイムリープを繰り返す!?効率的な新しいシミュレーション技術
2024.05.22
東大、電子回折パターンの減少とエントロピー増加の対応を実証
2024/06/03
理研など、「スキルミオンひも」の観察とその詳細な融解過程の記録に成功
2024/05/23 19:29
東大など、金属3Dプリント中の2D画像から3D多孔質構造を予測する手法を開発
2024/06/03
91 名前：デフォルトの名無しさん mailto:sage [2024/06/10(月) 23:46:59.09 ID:gkT1iazs.net]: >>84
スライスだから&[x][..]だね
92 名前：デフォルトの名無しさん [2024/06/11(火) 05:30:39.25 ID:7n9sgmId.net]: 男性の精子の減少、携帯電話の使用と関係か最新研究
2023/11/02
https://www.cnn.co.jp/fringe/35211064.html
放射線と被曝
https://www.kan-etsu-hp.ne.jp/wp-content/themes/kan-etsu-hp/assets/kanetsu-hospital/department/pdf/radiology/radiation.pdf
>>エネルギーが極端に大きくなると X 線やガンマ線と呼ばれる放射線の一種になります。
※電磁波音波攻撃被爆している?

MrIは強力な磁場を利用しているので被爆しない

冷凍した人間の脳組織を解凍した後も正常に機能する技術開発
2024.05.12
https://karapaia.com/archives/52331859.html

1立方ミリメートルの脳の断片をハーバード大学とGoogleの研究者がナノメートル単位で3Dマッピングすることに成功
2024年05月10日
https://gigazine.net/news/20240510-human-brain-mapped-in-spectacular-detail/
幼児期の脳活動から18歳時点でのIQを予測できるという研究結果
2023/09/09
https://gigazine.net/news/20230909-brain-activity-toddler-predict-18-iq/

パーキンソン病の原因物質、脳内の可視化に成功
2024年6月6日 0時00分
https://www.asahi.com/articles/ASS652V7RS65ULBH00GM.html
東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961238/
93 名前：デフォルトの名無しさん [2024/06/11(火) 05:31:04.86 ID:7n9sgmId.net]: 日常的な蓋内全体の脳脊髄液の動態をマクロ的に観測する手法の開発に成功
2024/06/07
https://news.mynavi.jp/techplus/article/20240607-2961214/
細胞の内部を鮮明に観察できる蛍光顕微鏡技術を開発阪大など
2024/05/07
https://news.mynavi.jp/techplus/article/20240507-2941335/

脳が鮮明に見える！世界最強の磁束密度で脳をスキャンするMRI「イズールト」
2024.04.05
https://nazology.net/archives/148090
※5分で全身スキャン完了するのかな
94 名前：デフォルトの名無しさん [2024/06/11(火) 06:55:26.94 ID:3zjiFVVb.net]: 電磁波兵器の特許情報/Google検索で下記が判明
電磁波過敏症低周波騒音被害の症状が出現

設立 1998年テクノロジー犯罪の撲滅
Https://media.toriaez.jp/s2972/32686.pdf
P77-身体・運動機能が遠隔から操作される P78-五感が遠隔から操作される
ギャングストーキングと電磁攻撃 - 広島修道大学学術リポジトリ
https://shudo-u.repo.nii.ac.jp/record/3395/files/SG63205.pdf

下記を頭部などで再現

人間の「第六感」磁気を感じる能力発見
2019/03/19
https://www.sankei.com/article/20190319-6UGPQVLP4BLEDJYGVSX3WW6A4A/
髪の毛ほど薄いのに音を75％カット！MIT開発の「革新的防音カーテン」
2024.05.13
https://nazology.net/archives/149896

言葉に出さずとも内なる声を解読する、脳の読み取り装置が解発される
2024.05.20
https://karapaia.com/archives/52331884.html
95 名前：デフォルトの名無しさん mailto:sage [2024/06/11(火) 22:42:05.37 ID:r1NSY/4p.net]: >>90
配列でもベクタでも[..]を付ければスライスへ変換されるわけか
96 名前：デフォルトの名無しさん [2024/06/11(火) 23:50:24.15 ID:3zjiFVVb.net]: 【AI】IQ100超えを達成したAIモデルのClaude 3は「いい性格」を持つようにトレーニングされている [すらいむ★]
https://egg.5ch.net/test/read.cgi/scienceplus/1718025035/l50
97 名前：デフォルトの名無しさん mailto:sage [2024/06/12(水) 00:41:51.20 ID:wUm4+4hy.net]: ゼロから学ぶＲｕｓｔ　システムプログラミングの基礎から線形型システムまで (ＫＳ情報科学専門書)

Kindleで本日のみ￥500
98 名前：デフォルトの名無しさん mailto:sage [2024/06/12(水) 13:31:07.00 ID:6YNIMY/v.net]: Rustの作者と対話をしなくてもRust上級者になれるのは
作者の心を正確に読めるからではなく
あまり正確ではない当てずっぽうと試行錯誤が嫌いではないからだと思う
99 名前：デフォルトの名無しさん [2024/06/12(水) 17:47:51.37 ID:D5Lyqx4l.net]: はじまた
https://www.youtube.com/live/GiVA0MiHCV0
100 名前：デフォルトの名無しさん mailto:sage [2024/06/12(水) 21:31:56.44 ID:t2XH+QPZ.net]: >>94
どちらも
101 名前：std::slice::SliceIndexによるものだが その前にVecはstd::ops::Derefでsliceに変換されるのに対して 配列はstd::marker::Unsizeが実装されていて std::ops::CoerceUnsizedでsliceに変換される点が異なる []: [ここ壊れてます]
102 名前：デフォルトの名無しさん [2024/06/13(木) 02:53:52.72 ID:PAaiBuyr.net]: 人間に匹敵する知能を持った汎用人工知能を開発した研究者に総額100万ドルの賞金を授与するコンテスト「ARC Prize」が開催
103 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 08:11:01.44 ID:xJ4qiDeD.net]: zlib-rsの0.2.0きたね
ttps://github.com/memorysafety/zlib-rs
104 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 08:58:47.14 ID:gxf+efas.net]: >>99
Vecはヒープに依存し、かつスタックに移動するのが不可能
「サイズ」を定義できないデータは（スタックに）移動できない

個人の感想です
が、これが「知能」だと思うよ
105 名前：デフォルトの名無しさん [2024/06/13(木) 11:16:55.93 ID:fHN6F3J2.net]: >>95
IQ=2x偏差値
106 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 19:02:11.26 ID:aZe1IsBk.net]: https://i.imgur.com/ujHucRs.jpg
もうすぐ終了です
107 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 19:06:39.65 ID:LjZDtVfU.net]: >>101
元のzlibとの速度差はどれくらい？
108 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 19:19:21.58 ID:bPri26wi.net]: >>104
ガンガンポイント増えるな
109 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 19:53:32.56 ID:jsa1Mw5+.net]: zlib-rsはzlibと比較してまだ圧倒的に足りてないからパフォーマンス評価のしようがない
ttps://github.com/memorysafety/zlib-rs/issues/49
110 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 21:05:44.12 ID:V9qdE8Kb.net]: >>107
先は長いね
111 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 21:29:59.05 ID:/G8REiwP.net]: RustはC/C++に置き換わるのか？
112 名前： mailto:sage釣 [2024/06/13(木) 21:36:14.88 ID:1OdwwcYl.net]: 無理無理かたつむり
113 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 21:37:00.52 ID:gxf+efas.net]: 計画も陰謀もないんだよ
114 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 21:59:02.47 ID:5nBUoDRv.net]: >>104
めっちゃ面白そう
　
115 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 22:16:54.37 ID:jsa1Mw5+.net]: >>109
時間さえあれば
116 名前：デフォルトの名無しさん mailto:sage [2024/06/13(木) 23:52:05.18 ID:zLnkTNXF.net]: >>109
C/C++がRustに置き換わっていってる
117 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 08:05:53.63 ID:5fkgUscQ.net]: >>109
その前にSafe Rust相当のsafe c++とか出るんじゃない？
標準化できるかわからんが。
118 名前： mailto:sage釣 [2024/06/14(金) 08:11:27.55 ID:n78hEtXN.net]: C++はUTF-8の扱いを何とかして欲しいね。
119 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 08:28:16.67 ID:Rk5MFfRB.net]: >>115
C++をいくら強化してもそれは不可能だと皆がわかった
既存C++資産メンテ用限定としてはCarbonがある
それ以外は全てがRustへの移行に向かっている
120 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 08:44:54.37 ID:5fkgUscQ.net]: >>117
別のサブセットを作るだけだよ。
unsafe rustに対するsafe rustみたいなもの。
121 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 08:53:45.79 ID:Rk5MFfRB.net]: >>118
それは無理だとわかったので誰も進めていない
122 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 08:54:29.15 ID:/xTQkr0X.net]: C++やってればそれが不可能なことくらいわかると思うんだけどな
123 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 08:56:27.95 ID:ZAmC1x49.net]: 聖地に向かっている者だけが地政学を信じている
124 名前：デフォルトの名無しさん [2024/06/14(金) 09:19:59.81 ID:g3k7S7zc.net]: >>109
現在進行形だけどC/C++が絶滅するわけじゃなさそう
125 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 10:01:07.05 ID:lj8dYX/x.net]: >>115
C++のロードマップを見てくると良いよ
126 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 11:03:03.69 ID:GO4uoc83.net]: 今考えられてるアノテーションではmaybe safer C++になるだけで根本的にsafe�
127 名前：ﾅはない 既存資産を活用するという最大のメリットを捨てて非互換新言語を作れば可能だけどRustがある現状で誰もそんな事に投資しないから実現不可能 []: [ここ壊れてます]
128 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 11:28:58.36 ID:O+avA7Kj.net]: >>117
carbonとか完全に忘れてたわ。あれ絶対c++やRustより先に無くなるやろ
129 名前：デフォルトの名無しさん [2024/06/14(金) 17:00:20.45 ID:wrlhIGAu.net]: https://imgur.com/a/layer-A7vGJjY
使い分けは
こんなイメージ
130 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 17:29:32.96 ID:97A5EwfU.net]: C++を安全にしようとすると標準ライブラリの各インターフェースから全て作り直しとなり
標準でないライブラリも同様なので既存のコード資産は使えず全面書き直しとなってしまう
それだけでは済まなくて互換性のない言語仕様も取り入れないといけない
なんとか手間暇かけてそこまで頑張って安全なC++ができあがっても何の意味もメリットも無くなってることに誰もが気付いた
131 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 17:31:19.78 ID:stz6yx5w.net]: 色使いが目にunsafeすぎる
132 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 18:01:13.88 ID:PWCt6Qaf.net]: zlib-rsで移植のほぼ完了したdeflateを見ればよくわかるけどすごくメモリ安全だぞ
現実を見ろ
133 名前：デフォルトの名無しさん [2024/06/14(金) 18:18:31.44 ID:49Oug44p.net]: >>109
ゲーム分野のC/C++は置き換わらない
134 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 18:24:39.72 ID:lj8dYX/x.net]: ゲームなんざ脆弱性があろうが最悪クラッシュさせりゃいいからな😁
まともなゲームエンジンフレームワークのないRustを使う意味がない
それよかクラッシュしたら人死の出るようなところのRust化が優先
135 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 19:04:14.04 ID:1kqNSQLr.net]: ネットワーク対戦ゲームだと細工したパケット送ると
バッファーオーバーフローで云々とよくある
脆弱性になるじゃん
136 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 19:13:14.40 ID:65JFUBxW.net]: >>132
そんなつまらない欠陥じゃなくてC++ではなくRust選ぶ利点になりえる脆弱性を言ってよ
137 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 20:42:46.16 ID:ZAmC1x49.net]: 今すぐ物を作るのは損
10年後20年後に作れば得
これがインフレだが
本当はどちらか一つだけ選ぶのは損で両方選ぶのが得だと思わないか
138 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 21:29:25.97 ID:1kqNSQLr.net]: >>133
あなたがつまらんかどうかが評価軸じゃないので
139 名前：デフォルトの名無しさん mailto:sage [2024/06/14(金) 22:51:10.89 ID:SfJORH/f.net]: >>134
>今すぐ物を作るのは損
>10年後20年後に作れば得
>これがインフレだが

違う
前提が間違ってるので議論が成り立たない
140 名前：デフォルトの名無しさん [2024/06/14(金) 23:07:33.93 ID:B5keN8zV.net]: C++書くのダルイんよ
Rustのゲームエンジン来るの待ってる
141 名前：デフォルトの名無しさん [2024/06/14(金) 23:46:55.69 ID:49Oug44p.net]: ゲームはまずdirectxやopenglとかがrustで書き直されないことには何も始まらんと思うわ
142 名前：デフォルトの名無しさん [2024/06/15(土) 00:13:27.25 ID:W+2t+gug.net]: この板はプログラムを作らない人のための板ですね
143 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 00:24:57.03 ID:mfm3bm5o.net]: 作ると断言するが、時の指定まではしていない
144 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 04:55:57.02 ID:ao0/TxVC.net]: >>138
WebGPUの参照実装であるwgpuを知らんのか。
ライブラリ使う側のIFはだいぶsafeだよ。
まぁ、バックエンドは結局、valkanやOpenGLになるけど。
145 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 06:54:41.07 ID:FwUehUa7.net]: >>138
それらは書き直されてもunsafeばっかになって意味ないだろ
146 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 07:07:04.66 ID:jiIbIudV.net]: OSのシステムコールだって生ポインタを渡したりunsafeな
147 名前：仕様だけど Rustはsafeなインターフェースのライブラリとして提供して安全に使われているよ []: [ここ壊れてます]
148 名前：デフォルトの名無しさん [2024/06/15(土) 08:12:25.38 ID:h+pAIb35.net]: AIに組み込まれた検閲による命令拒否を打ち消してあらゆる種類の質問に応答できるようにする「アブリテレーション」とは？
2024年06月14日
※自分の身近な人の嘘や陥れようかが話されたことと実際の動き【動画撮影含む】っを解析すれば判明
スポーツで動的シミレーションなどをする不正をしているや審判の判定がおかしいも判明
日常生活の動きも同時に併用されればボイス・トォ・スカルを使用しているかが判明

スマフォにAIが搭載されるので容易に判定
120フレームと8ｋ【人間の網膜の解像度と同じ】あればかなり制度が上がる

相手の望まない手助けは数週間持続する高いストレスを与える！
2024.06.13
↕サイコパスはどう考えるのかな
使えない人」を排斥するとき周りの人の心は痛みにくいと判明
2021.05.22 SAT
ネット上で問題発言をする人は、暗い性格特性「ダーク・トライアド」かもしれない
2021.04.02 FRI
ナルシストは他の人よりも早くCEOの地位にたどり着く
2021.02.09 TUE
つい被害者を責めてしまう「公正世界仮説」とは何なのか？
2019.07.22 MON
「無能」でもOK？　社会的地位の高い人ほど信頼されやすい理由とは
2019.06.02 SUN
149 名前：デフォルトの名無しさん [2024/06/15(土) 08:12:46.55 ID:h+pAIb35.net]: 「問題を指摘する人」に問題があると思い込む心理バイアス「自発的特性転移」が陰謀論を生んでいるという主張
2024年05
悪いニュースを伝えた人は理不尽に嫌われてしまうことが明らかに
2019.05.17
「恋人がサイコパス」だった時の見分け方とは
2018.12.09 SUN
ロンドン市民の娯楽だった？！近代イギリスの公開処刑
2023/12/17
スラップ訴訟
>>ある程度の発言力や社会的影響力のある、社会的に優位といえる立場の者が、特に発言力や影響力を持たない相対的弱者を相手取り訴訟を起こすこと。
巨大IT企業から「法的措置をちらつかせる停止通告書」を受け取った場合の対処方法とは？
2024年02月01日 08時00分
150 名前：デフォルトの名無しさん [2024/06/15(土) 10:23:21.15 ID:sguIT4c6.net]: サイバーエージェント、画像認識できる75億パラメーターの日本語LLM公開　商用利用OK
サイバーエージェントは6月13日、日本語大規模言語モデル（LLM）に画像認識機能を追加した大規模視覚言語モデル（VLM）「llava-calm2-siglip」を公開した。

「ChatGPT」画像を見ながら人間みたいに話せる新機能、今後数週間でリリースと予告
OpenAIは6月14日、同社の公式Instagramアカウントを通じ、ChatGPT（GPT-4o）に音声と映像を同時に理解する機能を追加し、今後数週間以内にリリースすると発表した。

画像生成AI「Stable Diffusion 3 Medium」公開　プロンプトの理解力が上がり、リアルな画像が生成可能に
Stability.aiは6月12日、同社が開発する画像生成AI「Stable Diffusion 3」シリーズの最新モデル「Stable Diffusion 3 Medium」を発表、無償の非商用ライセンスおよびクリエイターライセンスの下で利用可能だ。
サイバーエージェント、画像認識できる75億パラメーターの日本語LLM公開　商用利用OK
サイバーエージェントは6月13日、日本語大規模言語モデル（LLM）に画像認識機能を追加した大規模視覚言語モデル（VLM）「llava-calm2-siglip」を公開した。

「ChatGPT」画像を見ながら人間みたいに話せる新機能、今後数週間でリリースと予告
OpenAIは6月14日、同社の公式Instagramアカウントを通じ、ChatGPT（GPT-4o）に音声と映像を同時に理解する機能を追加し、今後数週間以内にリリースすると発表した。

画像生成AI「Stable Diffusion 3 Medium」公開　プロンプトの理解力が上がり、リアルな画像が生成可能に
Stability.aiは6月12日、同社が開発する画像生成AI「Stable Diffusion 3」シリーズの最新モデル「Stable Diffusion 3 Medium」を発表、無償の非商用ライセンスおよびクリエイターライセンスの下で利用可能だ。
151 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 11:03:47.63 ID:8Y+G0brA.net]: >>143
それなら既存のRustラッパーでよくね？
152 名前：デフォルトの名無しさん [2024/06/15(土) 12:50:26.14 ID:lxZB8+rK.net]: 根っこの技術がc/c++製でガワだけrustで、それでc++を置き換えたと言えるのか？
153 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 12:55:07.64 ID:pv+Dr0CG.net]: >>148
置き換える意味があるかないかの問題でしょ
ほぼシステムコールなグラフィックAPIのRust実装の有意義性はあるのか
154 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 13:06:53.11 ID:I+z8iAZu.net]: >>148
根っこを捨ててpure Rust で再構築したとして
それは置き換えたんじゃなくて
別のものを似せて造り治しただけじゃないのか
155 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 13:08:57.41 ID:I+z8iAZu.net]: >>149
完全に pure Rust の OS があったとして
その上で動くアプリケーションは全て Rust で描かないといけない世界が良いのか
Rust OS の上でも C/C++ で開発したい(API は C 相当)のかで意見が変わる
156 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 13:33:19.67 ID:mfm3bm5o.net]: 完全に純粋に一人で打席に立つことは
そいつの年収やそのカネの所有権を定義するのに必要みたいな感じでしょ
157 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 15:03:07.44 ID:jiIbIudV.net]: 勘違いしてる人が多いようだけど
Rustの目的は全てをRustで書くことではなく安全にすることなんだよ
だからOSシステムコール呼び出しもRust(と最小限の各アーキテクチャ毎のレジスタ積み等)で頑張るのではなくCで書かれたlibcを用いている
つまりRustのunsafe部分を最小限にするとともに、unsafeだが枯れて安全なlibcを活用している
158 名前：デフォルトの名無しさん [2024/06/15(土) 15:11:35.25 ID:W+2t+gug.net]: 勘違いしてんのはここでまともなRustの話ができると思ってるお前だよ
159 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 15:51:53.03 ID:uRWofhsS.net]: 概論でいいんならこれ貼るよ

オブジェクト指向を学ばなかった話
https://qiita.com/adaiimps/items/e04ae03371435aeffe87
160 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 15:54:39.14 ID:I+z8iAZu.net]: 自分は pure Rust に全然拘っていないし
むしろ unsafe 大好きだが
pure Rust に拘ってる人や
unsafe 絶対無くせって言ってる人も居るのを知ってる
後者は基地外
161 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 16:13:09.69 ID:uRWofhsS.net]: use std::io::{self, BufRead, BufReader};
const FULL_BITS: u32 = (1 << 26) - 1;
fn main() {
　let mut shortest: Option<String> = None;
　for line in BufReader::new(io::stdin()).lines() {
　　let line = line.unwrap();
　　let mut bits = 0;
　　for b in line.as_bytes() {
　　　let index = match b {
　　　　b'A'..=b'Z' => b - b'A',
　　　　b'a'..=b'z' => b - b'a',
　　　　_ => continue,
　　　};
　　　bits |= 1 << index;
　　}
　　if bits != FULL_BITS {
　　　continue;
　　}
　　if let Some(ref shortest) = shortest {
　　　if shortest.len() < line.len() {
　　　　continue;
　　　}
　　}
　　shortest = Some(line);
　}
　if let Some(shortest) = shortest {
　　println!("{shortest}");
　} else {
　　eprintln!("ERROR: no matched lines");
　}
}
162 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 17:55:06.95 ID:uRWofhsS.net]: ソースコードのコピペで止まるスレ
163 名前：デフォルトの名無しさん [2024/06/15(土) 20:29:16.21 ID:x7/eMzge.net]: ソースコード貼るなんて暴力ですよ！
164 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 21:06:34.26 ID:uRWofhsS.net]: コピペしただけなんだけどね

mevius.5ch.net/test/read.cgi/tech/1691038333/6
165 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 21:09:34.98 ID:jiIbIudV.net]: >>156
unsafeは好き嫌いというよりも
最下層のCPUとメモリもしくは境界のFFIで必須な存在とみるべきではないかな
ただしそこだけにunsafeを閉じ込めて一般プログラマーはsafeなインタフェイスのみを使う
166 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 21:10:47.55 ID:uRWofhsS.net]: 一行のコードも書かずに形而上学みたいにプログラミングを学ぶ贅沢はいいね
167 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 21:54:03.45 ID:uRWofhsS.net]: Rust「で」作るんじゃなくてRust「を」作る秘密が知りたいんだよね
すべてのソースコードがコンパイル時に手元にあったとして、メモリの使途を解析してしまえるなんて普通は思わないからね
この点を「たまたま思いついた天才がいた」で済ませたくない
168 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 22:10:08.33 ID:uRWofhsS.net]: Copy型とそうでない型。よろしい
Copy型の自動変数みたいにそうでない型もスコープを抜けると解放。それはよろしい
しかしそんなものは遥か実用に遠い
169 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 22:29:19.17 ID:uRWofhsS.net]: いったい何がきっかけでメモリの使途を把握してしまえるかもと思ったか
それが分かるまでごくごくゆっくりとしか勉強しないよ
170 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 22:33:28.01 ID:mfm3bm5o.net]: ヒープを一切使わないパラダイムは昔に戻っただけ
スタックの安全性だけを考えてヒープはライブラリに任せる
171 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 22:46:06.16 ID:uRWofhsS.net]: 全部スタックでやってるって本当の話なの？
172 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 22:51:02.34 ID:uRWofhsS.net]: allocaとかとっくにあったよ？
173 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 23:22:17.89 ID:uRWofhsS.net]: 逆のものを想像してんだけどな
スタックでなくヒープにあっても同じなのがRustじゃないの？
174 名前：デフォルトの名無しさん mailto:sage [2024/06/15(土) 23:47:36.34 ID:mfm3bm5o.net]: 参照の寿命が尽きても参照元のデストラクタは呼ばれない
だから参照元がヒープにあろうがなかろうが参照の寿命はスタックに基づいて決めてしまえば良い
175 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 00:42:56.54 ID:DhqUa2Zy.net]: >>170
「参照元」は誤用か
参照先と言うべきだったか
176 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 00:50:00.04 ID:+a7ueRP7.net]: >>169
スタック上への参照とヒープ上への参照をRustでは区別しない
ライフタイムさえ満たしていればどこを指していても区別なく参照を扱う
そのため、従来行われてきた「安全にヒープ上でに領域を確保してヒープ上への参照を返す」をしなくても
ライフタイムさえ満たしていればスタック上への参照を安全に渡したり返したり自由にできるようになった
そのため、従来はヒープ上に確保していていたケースがRustではスタック上に置くことができるようになり、その点でも高速化に寄与している
177 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 01:00:26.12 ID:d8h4GcS0.net]: 複オジのレスはいつも通り8割は嘘だな
178 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 01:15:13.88 ID:dwkxcYMW.net]: >>172
別にC言語だってallocaの返したポインタとmallocの返したポインタを区別しないけど
179 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 01:25:03.80 ID:J8bJz9x+.net]: 誰が解放するか責任もなく解放忘れや多重解放を生むＣ言語は論外だろ
解放されたスタックフレームやヒープエリアを指し続けているポインタが残ったりな
180 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 01:32:46.10 ID:dwkxcYMW.net]: C言語と違って区別しないわけじゃないし、C言語と違って高速ってわけでもない
181 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 01:39:48.74 ID:dwkxcYMW.net]: C言語同様に区別しないし、C言語同様に高速なんでしょう
182 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 01:45:22.24 ID:sswa3N72.net]: そろそろ自己隔離しとけザコども

結局C++とRustってどっちが良いの？ 9traits
ttps://mevius.5ch.net/test/read.cgi/tech/1701997063/
183 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 03:32:45.56 ID:dwkxcYMW.net]: へえ、コピーじゃなくて移動をデフォにしちゃうのか
184 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 04:03:11.69 ID:WxpyLfm8.net]: >>174
mallocで得たポインタとallocaで得たポインタは明確に区別しなければならない
mallocで得たポインタのみfreeの対象としなければならない
この区別�
185 名前：ﾍCプログラマーの責務でありミスると破綻する []: [ここ壊れてます]
186 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 04:10:20.19 ID:dwkxcYMW.net]: >>180
コンパイラが区別してくれるわけじゃないからそう書いた
今はRustコンパイラの秘密を探ってるんだし
187 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 04:28:58.35 ID:QdGU/f8s.net]: Rustはヒープで確保したメモリ領域も完全自動で安全にメモリ解放されるからプログラマーの負担がなくていいよね

ヒープへの参照とスタックへの参照に区別がないだけでなく
それらをたとえ混ぜて関数間で渡したり返したりたらい回しにしても安全で
もし安全でない使い方をした時はライフタイムが切れてコンパイルエラーになるから自由と安全が両立されてるね
188 名前： mailto:sage釣 [2024/06/16(日) 04:37:34.79 ID:qe+k+ZN3.net]: 解放されたスタックフレームが残って、どうやって呼び出し元に帰るつもりなんだろう。😱
189 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 04:43:29.58 ID:dwkxcYMW.net]: メモリはコピーじゃなくて（所有権の）移動がデフォ
所有者がスコープを抜けるとメモリは解放
所有者に別の値が代入された際もメモリは解放
代入元は所有権が移ると未初期化の扱いになる

これだけでもかなり面白いね
190 名前：デフォルトの名無しさん [2024/06/16(日) 04:50:45.28 ID:/uiI2ckT.net]: >>183
C/C++/Rustすべて関数が呼び出し元に戻るときにスタックフレームは自動解放されます
もしその破棄されたスタックフレーム上を指すポインタ(参照)がどこかに残っていた場合、
C/C++ではそのポインタ使用でそこをアクセスしてしまい気づかないバグや穴となるでしょう
Rustではコンパイル時点でライフタイムエラーとなるため問題が起きないです
191 名前：デフォルトの名無しさん [2024/06/16(日) 05:46:32.57 ID:Jxkkspwa.net]: 正体不明のボイス・トォ・スカル
マイクロ波聴覚効果の機能より

神の声兵器は機器の場所が割れているので
ハッキング下と奪取後に器機を複製できた音を宣言していた

電磁波音波なのでむやみに器機に仕掛けると誰かが攻撃しているとすぐに設置したものは察知するが
その監視網をかいくぐるということは一発で危機をジャックしたことになる

そして機器の性能は年々よくなるので自分に行って見分けがつかないくらいになると器機使用者が幻覚を見ていると錯覚し始める
192 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 06:03:13.93 ID:dwkxcYMW.net]: メモリはそれ自体は無論のこと、それを指すポインタもひとつしかないわけだ
193 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 07:56:02.10 ID:dwkxcYMW.net]: この発想は正直なかったわ
ひとつのメモリをあちこちから参照すればするほど高効率みたいな思い込みがあるからね
194 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 10:08:57.93 ID:R4/urzCg.net]: >>167
>全部stack
そういう描き方をすればそうなるってだけで
そういう描き方ならCでも出来る
195 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 10:11:02.64 ID:R4/urzCg.net]: >>169-171
CにBoxを導入すれば解決
196 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 10:13:30.02 ID:R4/urzCg.net]: >>173
ほんそれ
197 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 10:32:48.33 ID:dwkxcYMW.net]: で、配列の要素だったり構造体のメンバだったりは「移動済み」にできない？
198 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 10:36:59.18 ID:dwkxcYMW.net]: とにかく&をつければアドレスを借用できて、その生存規則違反はコンパイラがはじく、と
199 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 10:41:20.79 ID:irw16nD2.net]: 新参に教えといてあげると
172, 175, 180, 182あたりはすべて複製おじさん(通称複オジ)という同一人物だよ
知ったかぶりで出鱈目ばかり書いて全く反省しないという
悪い意味で有名な人ので騙されないように注意してね
200 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 10:51:27.98 ID:DhqUa2Zy.net]: 1日10行推敲するより1日1万行書いた方が数値化に貢献しやすいからしょうがない
201 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 11:21:38.24 ID:dwkxcYMW.net]: ボローチェッカーは作るのも使うのも難しそう
よくこんなこと可能だと思ったもんだ
202 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 11:48:19.48 ID:dwkxcYMW.net]: Rustの中ではつまらないというか泥臭い部分だね
203 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:06:57.33 ID:0Wwb3VFz.net]: >>196
ライフタイムについてまじめに知りたいなら（ある程度Rustには慣れた前提として）NLLのRFCを読むのをおすすめしたい
ttps://rust-lang.github.io/rfcs/2094-nll.html

そろそろこれよりいい資料は出ないもんかね……というかReferenceに明記してもらえんかね
なんか1.79でも地味にルールが拡張されたようだし
204 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:23:11.10 ID:dwkxcYMW.net]: ええっと、メモリの所有者が
・スコープを抜けること
・別の値が代入されること
・別の変数に所有権を移動させること
はもともと検出できる前提なのだよね
ボローチェッカーと言ってもその３つの組み合わせに毛が生えた程度なのかどうか
205 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:27:02.82 ID:EH7/X6SF.net]: >>198
全ての言語仕様を「仕様書」としてまとめる提案は出ているんだけど何年も動きがないんだよね……
206 名前：デフォルトの名無しさん [2024/06/16(日) 12:30:31.60 ID:M/AsARsj.net]: >>174
allocaで得たポインタfreeしてそうなコメントだな
207 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:32:49.98 ID:EH7/X6SF.net]: >>199
メモリとかアドレスとか言ってる時点で正確な理解から遠いと思う。
変数はメモリではないし、参照はアドレスではない。
処理系の実装としてはそのように対応するという想定はあるだろうけど機械語レベルの事情と言語のルールはレイヤが違う。
208 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:33:46.16 ID:dwkxcYMW.net]: >>201
機械語知ってるからそんな心配はない
209 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:36:26.13 ID:dwkxcYMW.net]: >>202
そうだね。Rustは高級アセンブラってわけではまったくないね。勘違いしてた
210 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:42:20.38 ID:dwkxcYMW.net]: 代入だったり関数呼び出しの引数だったりはコピーじゃなくて移動がキホンって時点で機械語ともC言語とも違う
211 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 12:51:16.07 ID:G6A3UH2o.net]: >>205
代入と考えるよりもパターンマッチングと考えるといいかな
＝や引数などで複雑なパターンを書いてもマッチングしてくれるよ
それがたまたま1対1の時が昔からの代入に相当してマッチングして移動
212 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 13:26:09.91 ID:Crm/SwBu.net]: あえて機械語レベルでも考えるとするなら概念的には移動でも (最適化を別にすれば) ビットパターンはコピーしている。
所有権を失った変数にはアクセスできないように静的に制限されるから所有権が移動したように見える。
借用は (借用が存在している間は) 移動を許さない権利として捉えることができる。
213 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 13:35:38.29 ID:wnp+0tyF.net]: >>200
現状だとここを見ておくのがいいかも
https://public-docs.ferrocene.dev/main/specification/index.html
ISO 26262の認定通すために書かれたものだからかなりちゃんとしている
214 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 15:11:48.05 ID:xaMJYqDm.net]: >>208
C/C++はISO認定だからな
一方、Rust連中はほんぽん仕様変える(変えたい)から、そんなISOレベルの仕様書書く意味がないって感じじゃないのか
215 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 15:51:37.66 ID:Crm/SwBu.net]: >>209
C++ だって三年ごとに更新する制度になってるし、その間の議論でも仕様の文面をどう変えるかという形式をとる。
頻繁に変えるつもりがあるならなおさら今どうなってるのかの全体像を把握できる仕組みがないと困る。
216 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 15:52:59.06 ID:sKPbV2Nu.net]: RubyもISOになったことあるし
217 名前：デフォルトの名無しさん [2024/06/16(日) 15:57:39.35 ID:sswa3N72.net]: 15.4:16 ??? (this should describe the order of borrowing and when the borrow is returned)

わろた
218 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 16:23:56.88 ID:dwkxcYMW.net]: NLLというくらいだからもともとLL
219 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 16:49:41.43 ID:dwkxcYMW.net]: まあ一応（ボローチェッカーというものが）可能そう
220 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 17:20:46.77 ID:dwkxcYMW.net]: コンパイラはプログラム中の全ての参照型に対してライフタイムを割り当てる、と
221 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 17:45:29.17 ID:WRdAUcGE.net]: 言語にISO標準を求めるのって相当なお爺ちゃんでしょ
もうそういう時代じゃないですよ
222 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 17:52:05.41 ID:fzWVLbYH.net]: >>215
所有者がどのスタックフレーム(の中のどのブロックスコープ)にいるかだけの話だよな
そこより先なら参照は生きて
そこより元なら参照も死ぬ

もちろんそんな神の絶対的な視点を実行前のコンパイル時点で静的に持つことはできない
しかし各関数内での出入り(引数がinで返り値がout)は静的にわかるから
相対的な視点で有効か無効かわかることになると
223 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 17:55:19.72 ID:Crm/SwBu.net]: >>216
ISO 規格が必要なんて話はしてないだろ。
仕様書が要るって話をしてるんだぞ。
224 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 18:05:26.18 ID:0Wwb3VFz.net]: 複製おじさんと遊ぼうスレ
225 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 18:43:24.33 ID:hxwMVp5d.net]: >>218
>仕様書が要るって話をしてるんだぞ。
別に全然要らないぞ
逆になんで要るんだ？
226 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 18:44:48.95 ID:dwkxcYMW.net]: ひとつしかない所有者がスコープを抜ける、もしくは所有者に別の値が代入されると、そこから先にはメモリはもうない
227 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 18:57:47.09 ID:dwkxcYMW.net]: なんとなく、所有者はスタックの根元の方に、参照はスタックの枝葉の方にいそうなイメージ
228 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 19:01:15.44 ID:4AvHozuz.net]: >>221
有効な参照(借用)が存在したまま移動や破棄は起きない
これは静的に判定されコンパイルエラーとなる
229 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 19:08:46.55 ID:dwkxcYMW.net]: >>223
つまり所有権も静的に解析できる？
230 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 19:26:50.69 ID:0Wwb3VFz.net]: ここは結局こんな感じなのでID:dwkxcYMWは本当のことが知りたいならrust-lang-jpのZulipにでも行くといい
ttps://rust-lang-jp.zulipchat.com/
231 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 21:12:46.18 ID:Crm/SwBu.net]: >>220
じゃあ言語の仕様をどうやって把握すんの？
何が出来ていれば Rust のコンパイラを実装できましたって言えるの？
232 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 21:13:16.76 ID:Crm/SwBu.net]: >>224
できるというか、それが Rust のキモやで。
233 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 22:06:19.67 ID:DhqUa2Zy.net]: ゴールポストを固定することが正しいという考えが衰退したんだよな
正しさを疑うことが常識になったから
234 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 22:29:00.55 ID:Crm/SwBu.net]: >>228
ゴールを設定したいという話じゃなくて「今」どうなっているか見えないと疑うべきものすら存在できないって話なんだよ。
235 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 22:37:41.81 ID:ICtaqBL/.net]: >>226
>じゃあ言語の仕様をどうやって把握すんの？
言語の仕様はリファレンスで把握しろよ

>Rust のコンパイラを実装できましたって言えるの？
言える必要性が全くないやろ
どうしても言いたければ公式が用意してるコンパイラと標準ライブラリのテストを全部通したらいいんじゃね？
236 名前：デフォルトの名無しさん mailto:sage [2024/06/16(日) 23:02:11.93 ID:Crm/SwBu.net]: >>230
端的に言うと現状のリファレンスマニュアルで Rust の仕様の全てを読み取ることは出来ない。
そのことは >>198 あたりからの話題の流れ。
リファレンスマニュアルは仕様を書くものじゃないし。
237 名前：デフォルトの名無しさん [2024/06/17(月) 06:58:24.07 ID:Yz55GwEO.net]: 【マイクロ波センサー】長距離でも壁があっても動きを検出！
↓2010年ごろには完成
高齢化社会を支える“見守りシステム”の開発に成功-カギを握った半導体ソリューションとは
↓2026年ごろにさらに性能工場
旭化成、ミリ波・マイクロ波帯の空洞共振器による微小金属検査システムを開発

男女関係なく陰部を撮影
一度でも盗撮されていれば正確な色合いの・・・
初期型は赤外線センサー【自動ドアのセンサなど】

子どもが言語を獲得していくのと同じようにAIモデルに学習させることに成功
AIを使って「赤外線カメラ画像のフルカラー化」に成功！

世界中で横行
238 名前：デフォルトの名無しさん [2024/06/17(月) 16:27:54.49 ID:prlYSpwu.net]: 役に立たないどんぐり
239 名前：デフォルトの名無しさん mailto:sage [2024/06/17(月) 21:23:17.19 ID:McDpAz4n.net]: 卒業式でみんなで思い出を言うやつみたいだな

卒業生　「そして役に立たないどんぐり！」
卒業生一同　「どんぐり～」
240 名前：デフォルトの名無しさん mailto:sage [2024/06/17(月) 21:51:46.63 ID:McDpAz4n.net]: 卒業生A　「高速で動作しながら保たれる高いメモリ安全性」
卒業生一同　「安全性！」
241 名前：デフォルトの名無しさん mailto:sage [2024/06/17(月) 22:06:12.81 ID:JE6O5Al9.net]: 米ホワイトハウス「ソフトウェアはメモリ安全でなければならない」との声明を発表：「C」「C++」よりも「Rust」などの言語を推奨
https://atmarkit.itmedia.co.jp/ait/articles/2403/18/news045.html
242 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 00:33:44.73 ID:Vx2LO8pn.net]: 卒業生　「みんなで借りた所有権」
卒業生一同　「所有権！」
243 名前：デフォルトの名無しさん [2024/06/18(火) 02:26:00.95 ID:V90mUrMq.net]: AIにC++とRustのコードを比較してもらった
https://nshinchan01.hateblo.jp/entry/2024/06/18/021159
244 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 08:51:41.62 ID:Ee6IUiqA.net]: 見えない仕様書より見えているコロンブスを殴る
殴る
245 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 09:12:34.89 ID:z6V+MJXC.net]: >>238
sum()自体は使わないとしてこうかな

fn foo(input: impl IntoIterator<Item = i32>) -> i32 {
　input
　　.into_iter()
　　.filter(|x| x % 2 == 0)
　　.map(|x| x * 2)
　　.fold(0, |sum, x| sum + x)
}

fn main() {
　let numbers = vec![1, 2, 3, 4, 5];
　assert_eq!(foo(numbers), 12);
}
246 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 12:23:59.59 ID:/B9kzKJY.net]: Rustの仕様と実装の分離ができてないと、公式の実装が唯一になるから困る分野があるんだろうね。
Cとかコンパイラいっぱいあるじゃん。

Rustぐらい複雑で成長途上の言語で仕様を文書化して実装を交換可能にするなんて事実上無理っぽいけど、10年後ぐらいには問題でてくるのかもね。
247 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 12:31:26.48 ID:28rDJLEQ.net]: >>241
現在のRustの仕様は実用的なプログラミングをする上で十分なレベルとなっているけど
さらに便利にするための追加仕様がTODOリストに積まれていてそれらが少しずつ解決されて追加されていってる状況ですね
まだ当面しばらくは現状体制のまま成長させていくのが望ましいと思います
248 名前：デフォルトの名無しさん [2024/06/18(火) 13:47:06.59 ID:4eNa7Q9X.net]: 実装が仕様でもいいけど、その場合はその実装のコアの部分を明確にした方がいいかもね
249 名前：デフォルトの名無しさん [2024/06/18(火) 13:51:40.72 ID:LAg3uLnk.net]: GPT-4oがAIベンチマークのARC-AGIで50％のスコアに到達、これまでの最高記録である34％を大幅に更新
2024年06月18日
※さらに最適化すれば７０%以上も可能な模様

スマホに搭載可能な小型透視チップが開発される
2024年06月18日
250 名前：デフォルトの名無しさん [2024/06/18(火) 16:50:36.49 ID:Q5+2E571.net]: >>241
Cの標準化の更新なんて10年とかだろうが。
251 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 18:04:47.12 ID:dU1vPCRC.net]: >>241
>Cとかコンパイラいっぱいあるじゃん。
それは各チップでそれぞれ別のCコンパイラが必要なのと
クローズドソースでプロプライエタリのコンパイラを有償で販売できる環境があるからだよ

Rustだと各チップで必要になるのはLLVM対応であってRustのコンパイラではないし
リスクをとってまでプロプライエタリなコンパイラをわざわざ作るメリットもほぼない
それにコンパイラが乱立しないというのは今のところはエコシステム的にはメリットしかない
252 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 19:09:22.28 ID:gzLiS43Q.net]: gccが頑張ってるくらい？
253 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 19:12:43.09 ID:1V33WRQR.net]: 団体がすべての主導権を握ってるならある日急にガラッと変えても誰も文句を言えない
実装が仕様です

C++や他の言語で規格がって言ってるのはコンパイラだけの問題じゃなくてコード利用してる側の都合でもある
254 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 19:12:43.05 ID:mK8t8Wj0.net]: Rust Foundation自身がrfc3355をmergeして仕様策定やります宣言してるのに
今更そんなこと言ってもね
255 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 19:36:21.60 ID:mK8t8Wj0.net]: そもそも、仕様を必要とするのはコンパイラだけじゃない

ttps://blog.rust-lang.org/2022/07/01/RLS-deprecation.html

少なくとも、公式がrustc依存のRLSを捨ててrust-analyzerへの乗り換えを宣言した時点から
「rustc実装が仕様」状態から脱却しなくてはならないという意識はRust Foundation内にもずっとあったと考えるべきだろう
256 名前：デフォルトの名無しさん mailto:sage [2024/06/18(火) 23:19:40.06 ID:AiI9Z/GF.net]: Rustのコンパイラを作るために理解すべき仕様と
Rustを使うために理解すべき仕様を
仕様という言葉で一括りにするから話がおかしくなる
257 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 01:01:46.69 ID:Xt21vW+E.net]: >>248
>C++や他の言語で規格がって言ってるのはコンパイラだけの問題じゃなくてコード利用してる側の都合でもある
コードを利用してる側の都合というのは複数の実装が存在するけど
リファレンス実装やデファクトスタンダードが存在しないから規格がないと困るからでしょ

今も規格が生きてる言語というとC, C++, COBOL, Ada, Fortran, JavaScript, C#くらい
C#を除くと各ベンダーがクローズドソースでプロプライエタリなコンパイラを作ってた時代からの言語
C#はOSS/マルチプラットフォーム化されて必要性はもうなくなってる
258 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 01:08:50.95 ID:8OfzU/dS.net]: Javaも、本家SunとGnuとあったな。今は知らんが
259 名前：デフォルトの名無しさん [2024/06/19(水) 04:09:25.16 ID:Z3xOIU7u.net]: ボイス・トォ・スカル
スポーツで試用しているとそっく露呈

選手の動きを撮影してそれを2倍.4倍...スロー再生すれば明確に使用しているを見つけられる
通常の者でも動けなくとも音と動作は見えているのでそれをシミレーション【通常の者主軸】にあてはめて動作をみればよい
それにプラスΑでそれが可能な回数を数学を用いて算出【科Ⓚ立論や物理的法則の確率論】すれば明らかにおかしいが判明

人間の筋肉量などを基本にの運動能力を設定しておくこと
さらに公共の場で日常生活のⓀ感の鋭さを調べれば本人がその能力があるかがわかる

知力の方は根気よく罠にかけるように会話をしていけば露呈する
260 名前：デフォルトの名無しさん [2024/06/19(水) 07:18:12.06 ID:Z3xOIU7u.net]: レーザーで「トリウム原子核」を励起することに成功、原子核時計などの革新的技術への道が開かれる
2024年04月30日

量子もつれの伝達速度の限界を解明することに成功！
2024/04/02

世界初！「量子もつれ」の画像撮影に成功
2019/07/15

量子テレポーテーションとワーム・ホールの移動速度判明
地球上に幽霊も神も観測可能なのになぜ観測不能?
量子テレポーテーション中は量子のもつれがないので双方観測不能
など考えましょう
261 名前：デフォルトの名無しさん [2024/06/19(水) 10:09:36.86 ID:Ml7xOhwE.net]: ここもう、ちゃんと教えてくれる上級者を追い出し終えてしまったと思う
初心者が自分以下の初心者にマウント取るだけのスレになってしまった
最後まで我慢して付き合ってくれた上級者まで汚い言葉で追い出して。
そんなんだからいつまでも下手なんだろうし、しょうがないか
262 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 11:17:34.73 ID:1p8aP5/l.net]: 上級者がいるとマウント取られてうざいから追い出し得だろ😅
263 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 17:53:51.50 ID:LFDUaW3g.net]: 質問です
イテレータから"名前1", "データ1", "名前2", "データ2", ...と渡ってくるのですが
これを(名前, データ)のイテレータに変換する方法、または、そのように扱える方法ありますか？
264 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 18:29:49.29 ID:sNVXKo+0.net]: 擬態初心者
265 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 18:44:02.73 ID:ZD2dEKbK.net]: >>248
気に入らないなら、フォークすれば良いじゃん
266 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 18:46:24.24 ID:n3c3jE4n.net]: パンがなければ？
267 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 19:22:09.94 ID:KTqBdjza.net]: >>256
書き込み規制が頻繁過ぎて信頼できないプラットホームだからだよ。
そもそも使えないことがあるのは内容がどうこう以前に論外。
268 名前：デフォルトの名無しさん [2024/06/19(水) 21:18:42.18 ID:djSYTMJZ.net]: このスレに上級者はいらねえ
真面目な質問をしたい時はissueか公式フォーラムかredditに行く
ここにはマウントを取って気持ちよくなるために来ているんだ
上級者は去れ
269 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 21:32:54.13 ID:DBUer5Kw.net]: >>258
1. itertoolsのtuples
2. nextを直接&指定回数呼び出すイテレータアダプターを書く
3. scan + filter_map
270 名前：デフォルトの名無しさん mailto:sage [2024/06/19(水) 23:58:52.30 ID:sOHW1UBs.net]: >>258
奇数個が来た時のエラー処理を考えると
Result<(名前, データ), 残り>を返すイテレーターが適切

>>264
tuples()は奇数個エラーに気付けないのが惜しい
271 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 00:27:34.04 ID:AP0fcOd2.net]: >>265
奇数個はエラーってのはタプルの要素数2個の場合限定なので
もう少し一般化して使える方法がいいと思うよ
itertoolsはchunksとか他にも使えるやつがあるから用途に応じて使い分けてね
272 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 00:30:45.20 ID:GE8fSxUT.net]: chunksは使いにくくタプルにするのも面倒だな
273 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 00:49:36.16 ID:1qQq2QC1.net]: 複おじに餌を与えないでください
274 名前：デフォルトの名無しさん [2024/06/20(木) 02:27:54.12 ID:s4SRXQdp.net]: いつの間にかHaskellがC#より速くなってた…。
https://nshinchan01.hateblo.jp/entry/2024/06/20/021327

HaskellとC#だけでなく、Rust/Pythonともベンチマーク比較してますのでどうぞ( ^^) _旦~~
（コードも掲載してるので、速度だけでなくコードの比較にもなってます）
275 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 08:11:10.55 ID:EWbar4Kg.net]: HaskellあればRustいらねーじゃん
276 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 08:16:50.61 ID:cxaQEnhn.net]: print!("");
この"!"いらんやろ
なぜ付けた
277 名前：デフォルトの名無しさん [2024/06/20(木) 08:54:48.96 ID:r+KYpvqW.net]: Haskellはもっと高速に動作するようにしてくれ
278 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 09:08:01.19 ID:868QLl9r.net]: >>271
!はマクロ

Rustは関数のオーバーロードがない
Rustは可変長引数もない

これらの弱点をマクロでおぎなっているんだよ
279 名前：デフォルトの名無しさん [2024/06/20(木) 09:25:21.08 ID:r+KYpvqW.net]: Rustはマクロをカジュアルに使いすぎ
280 名前：デフォルトの名無しさん [2024/06/20(木) 10:13:19.20 ID:gE9bPm4O.net]: 正体不明ぼいす・とぉ・すかる【非接触型ムーンショット一式】

AIも発展してきて論文全て読み込ませて作成可能のAI返答なので実在している

世界中の建前
器機所持者と機器秘所持者と機器非所持者ぼいす・とぉ・すかる＝非接触型ムーンショットそんな物無い!
かくなる上は統合失調症だ!
煩いので統合失調症を薬や自殺したことにしてカルテに!
さらに最近は作成しやすいので脇が甘いチームを見つけ次第コロナや感染症で死亡したことにします!

世界中の本音は現実は無慈悲
内臓疾患やバイオテロでの殺害!
統合失調症寿命を平均25年短く殺害!

非器機所持者に
世界で初めて固体電池を採用しパワー・安全性・耐久性・バッテリー寿命が超絶高まった最大出力4000Wのポータブル電源「YOSHINO B2000 SST」は家電を複数余裕で動かせてUPSとしても使用可能
2023年12月28日
※最上位は最大出力 6000w
これを最低4機?被害者に向けて配置して合計24000wの電磁波を集中できる配置にしていると犯人は宣言

ウナギの放電」は近くの生物の遺伝子を組換えていた!?
2023/12/11
281 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 12:40:54.14 ID:eIGp2b4r.net]: >>274
コンパイル時に展開して検証されるんだから、好ましくね？
実行時に解釈されて挙動が変わるJavaのアノテーションやRubyみたいなのよりよほど好ましいと思うが。
282 名前：デフォルトの名無しさん [2024/06/20(木) 12:47:30.50 ID:s4SRXQdp.net]: >>272
速いHaskellをお求めならIdris2が正格評価なHaskellという位置づけです。
無限リストを失うので、代わりにStreamとか色々概念が増えてるようですが。
（私は無限リスト含め、少ない概念でプログラミング出来るHaskellに惚れているので、速さはあまり気にしない）

一応、HaskellもTemplate HaskellでC++みたくコンパイル時実行して、ガシガシ定数に出来るのは定数にすれば速さも期待できますが。

>>270
HaskellはC#と同じくGCあるので、組み込みとかタイミングが命の金融系や車載系は向きませぬ…。
283 名前：デフォルトの名無しさん [2024/06/20(木) 12:50:51.75 ID:r+KYpvqW.net]: >>276
Rubyと比べて好ましいってのはなんの擁護にもなってないんだよな
むしろRubyと比較されうるというディスだろこれ
284 名前：デフォルトの名無しさん [2024/06/20(木) 17:05:35.72 ID:F8Q2DGBi.net]: >>276
同意します
285 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 17:45:56.15 ID:sFnTxIc/.net]: Rustのマクロは全言語の中でも優秀だからね
手続きマクロの強力さと利便性は他では代えがたい
宣言マクロももちろん衛生的(健全)で汚染がない
286 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 17:48:12.64 ID:Yb1hkWJo.net]: >>278
言語と言語の持つ機能を分離して評価できない方だったか。
287 名前：デフォルトの名無しさん [2024/06/20(木) 17:59:47.84 ID:/aYWwCEV.net]: >>281
いやRubyなんかどう分離してどこを切り取ってもRustと比較すること自体がRustへのディスだから
288 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 18:45:58.46 ID:zOlAS9GZ.net]: 使い分けのできないバカしかいないのかな？
289 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 19:23:04.79 ID:XVLgMtD/.net]: >>280
Lisp
290 名前： 警備員[Lv.20] mailto:sage釣 [2024/06/20(木) 19:39:03.89 ID:qDF/54rU.net]: >>280
forth
291 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 19:39:05.96 ID:sFnTxIc/.net]: >>284
Lispは衛生マクロではないため失格
292 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 20:00:53.20 ID:9lgCTTyf.net]: >>280
Scheme
293 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 20:05:57.11 ID:YFatQNUq.net]: Rustの手続き型マクロは構文木を自由自在に扱えるし、宣言型マクロは汚染がなく健全だから、Rustより上の言語は存在しないと思うよ
294 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 22:08:57.89 ID:0f6ktMCR.net]: paiza.ioでクレートを追加する方法を教えてください

https://i.imgur.com/RkQr1Wu.png
295 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 22:19:44.74 ID:XVLgMtD/.net]: Scheme の仕様 R6RS では識別子に文脈情報がくっついているモデルの手続き的マクロが導入されて伝統的マクロと衛生的マクロの統合がされた。
Rust のマクロが複数種類ある状況と、構文木とトークン列を行き来するモデルは(有用で強力だが)整理されてない不恰好さを感じるところはあるよ。
296 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 22:21:58.65 ID:p8EeWSs1.net]: 手続きマクロは別クレートが必要なのが面倒だし
いろいろと改善の余地はあると思う
297 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 22:53:46.34 ID:L3G38ey0.net]: >>267
>タプルにするのも面倒だな
chunkをtuples()すればいいだけだよ
面倒？
298 名前：デフォルトの名無しさん mailto:sage [2024/06/20(木) 22:59:31.43 ID:L3G38ey0.net]: >>265
>Result<(名前, データ), 残り>を返すイテレーターが適切
残りを扱いたい場合はイテレータが返す要素の一部として残りを表現するよりも
chunks_exactのようにイテレータを消費して終わった後に別途残りを取得できる形にしたほうが親切だよ
299 名前：デフォルトの名無しさん [2024/06/21(金) 01:29:07.25 ID:4fJ/I6Gh.net]: >>289
無理

ソースコピペでうまく行くケースもある
300 名前：デフォルトの名無しさん mailto:sage [2024/06/21(金) 05:51:59.15 ID:KnPUDwDa.net]: >>289
rust playgroundを使った方が良いと思われる
301 名前：デフォルトの名無しさん [2024/06/21(金) 06:59:01.53 ID:6/+cQ+0X.net]: >>289
そこでダメならideoneがあるじゃないか！
302 名前：デフォルトの名無しさん mailto:sage [2024/06/21(金) 09:59:00.28 ID:M8EEKVG+.net]: rust playground はチョットマシなだけで
五十歩百歩目くそ鼻くそ
303 名前：デフォルトの名無しさん mailto:sage [2024/06/21(金) 11:42:29.74 ID:M8EEKVG+.net]: >>289
巣に還れ
https://mevius.5ch.net/test/read.cgi/tech/1691038333/
304 名前：デフォルトの名無しさん mailto:sa []: [ここ壊れてます]
305 名前：ge mailto:2024/06/21(金) 12:58:06.76 ID:wIxdZD1d.net [ 乱数はこれを実装してみた https://ja.wikipedia.org/wiki/%E7%B7%9A%E5%BD%A2%E5%90%88%E5%90%8C%E6%B3%95 https://paiza.io/projects/q52q5NA88lQ0hnM2xsTOTA ]: [ここ壊れてます]
306 名前：デフォルトの名無しさん mailto:sage [2024/06/21(金) 14:07:02.11 ID:M8EEKVG+.net]: 久々に観掛けた static おじさん
307 名前：デフォルトの名無しさん mailto:sage [2024/06/21(金) 14:19:00.2 ]: [ここ壊れてます]
308 名前：0 ID:TK0ahnJz.net mailto: 競プロ勢だよ []: [ここ壊れてます]
309 名前：デフォルトの名無しさん mailto:sage [2024/06/21(金) 17:07:40.60 ID:wIxdZD1d.net]: staticやめてみた

https://paiza.io/projects/ooofhkI8laowBqzzDN6RsQ
310 名前：デフォルトの名無しさん mailto:sage [2024/06/21(金) 22:48:19.44 ID:zGyXPRVd.net]: >>292
tuples()は余っても余らなくてもNoneを返して終わってしまうため今回の場合はあかんね

>>293
chunks_exact()はイテレータには使えない
スライスは長さがわかっているから対応できるけど
311 名前：デフォルトの名無しさん [2024/06/22(土) 11:51:50.83 ID:7Ziu80uC.net]: すまんが、ClippyのAI版みたいなのってあるの？
Youtubeを見ていたら、「ClippyはAIのを除けば一番よく指導してくれる」旨を言ってる人がいてさ
AIの似たようなツールがあるって直接言ってるわけじゃないんだけど、なんか気になる表現をしてたんだ
あるんだったら使ってみたいな
312 名前：デフォルトの名無しさん mailto:sage [2024/06/22(土) 14:30:20.31 ID:boWDxemH.net]: 深い意味は無いので気にしすぎです
313 名前：デフォルトの名無しさん [2024/06/22(土) 15:07:04.48 ID:GlPOaJ+f.net]: 加熱するLLM開発競争に冷や水、オープンモデルの組み合わせだけでGPT-4o越えの事実
https://wirelesswire.jp/2024/06/86709/
314 名前：デフォルトの名無しさん [2024/06/22(土) 21:58:27.39 ID:9CBpYiTc.net]: >>304
それはRustに限らずプログラミング全般において「ChatGPTなどのAIに質問をすれば良い回答をしてくれる。そのようなAI系を除けばRustのClippyは良い仕事をしてくれる」という話だろう
「ClippyのAI版」という具体的なツールがあるわけでなく、もっと一般的な意味でのAIという文脈かと思う
315 名前：デフォルトの名無しさん [2024/06/22(土) 22:33:47.59 ID:dw6Bjmix.net]: >>304
Clippyは知らないが、自分のAIの使い方だとPythonでサンプルコードを書いて、Javaなりに変換するようにAIに投げる。
意図と違ったらその都度、こう直してって書いて微調整していく。って感じ。

Rustとかは雑誌の入門記事しか読んでないのに、関数型プログラミングバリバリのコードが出てきた。
（とはいえ元からPythonを意識した文法だったので、ほぼそのまんま）

fn main() {
for file_name in std::env::args().skip(1) {
println!("{}", file_name);
if let Ok(lines) = std::fs::read_to_string(&file_name) {
for (i, line) in lines.lines().enumerate() {
println!("{:>2}:{}", i + 1, line);
}
}
}
}
316 名前：デフォルトの名無しさん mailto:sage [2024/06/22(土) 23:41:03.46 ID:jxx0duBQ.net]: 関数型というとfor文使うのではなくこんなイメージ

fn main() {
　std::env::args().skip(1).for_each(|file_name| {
　　println!("{}", file_name);
　　std::fs::read_to_string(&file_name).map(|lines| {
　　　lines.lines().enumerate().for_each(|(i, line)| {
　　　　println!("{:>2}:{}", i + 1, line);
　　　})
　　})
　})
}
317 名前：デフォルトの名無しさん [2024/06/23(日) 01:55:08.61 ID:iAmtDmVE.net]: そうなんだけど、C#でやったらForEach使うためにやたらToListを経由させられて逆に読みにくくなった。

これはHaskellも無理に高階関数やモナド演算子(>>/>>=)ばかりじゃなくて、適度にリスト内包表記やdo記法も合わせた方が読み易いのと同じだと思う。
318 名前：デフォルトの名無しさん [2024/06/23(日) 02:43:59.44 ID:FDfmyhMX.net]: >>308 が関数型プログラミング *バリバリ* 何て書くからだろ。
俺も 308 のどこがバリバリ？と思ったわ。
関数型バリバリが読みやすいかどうかは別の話よ。
319 名前：デフォルトの名無しさん [2024/06/23(日) 04:04:02.58 ID:iAmtDmVE.net]: AIは現段階ではネットから拾ってくるだけだしね。
「もっと短くしてください。」を繰り返すと同じコードしか吐かない。
無理なら無理って答えろよっていう…。

それにしてもRustのfor_eachメソッドはindex行けるのか。羨ましい。
C#はSelectはindex使えるけどForEachは使えない。

逆にSelectはWriteLine使えないけどForEachは使えるという…。
（Forメソッド？が欲しい）

Rustはその辺、最初から関数型プログラミングを意識してるからfor_eachメソッド使ってもそこまで読み難くなってないな。
320 名前：デフォルトの名無しさん [2024/06/23(日) 04:08:15.53 ID:iAmtDmVE.net]: あ、＞AIは現段階ではネットから拾ってくるだけだしね。　っていうのは

for文を全く使わないようなコードは、Web上の（ユーザーの）評価も低いのでAIの評価基準でも選択されないって意味ね。
321 名前：デフォルトの名無しさん [2024/06/23(日) 09:12:12.96 ID:2+8typ11.net]: >>308
clippyは公式のコード改善ツールだよ
コンパイラはエラーと警告だけ出すけど、clippyはそれ以上のヒントをくれる
例えば「コンテナ中に条件を満たす要素があるかどうか」をチェックするために items.iter().find(条件).is_some() のようなコードを書いたら、それに対し items.iter().any(条件) というシンプルな書き方を提案してくれる
こういう関数や構文の置き換えを含む提案をしてくれるツールで、これがコンパイラと同じ標準機能として備わってる (追加インストール不要) のが便利
322 名前：デフォルトの名無しさん [2024/06/23(日) 09:41:40.50 ID:iAmtDmVE.net]: いい勉強になった。ありがとう。
323 名前：デフォルトの名無しさん mailto:sage [2024/06/23(日) 10:21:20.16 ID:ndMGRV9p.net]: >>312
for_eachの機能でindexにアクセスしてるんじゃなくて
enumerateで(index, value)の形に変換してそれをfor_eachしてるだけだぞ
標準でenumerate相当のメソッドが用意されてないだけで
ForEachでindexを扱うときはC#でも似たようなやり方になる
324 名前：デフォルトの名無しさん [2024/06/23(日) 16:42:06.61 ID:+hC7ZOW/.net]: 正体不明ボイス・トォ・スカル
正体不明ぶれいん・ましん・いんたーふぇいす
対になっているのか?

周囲も被害者の思考を聞いているのならわかるように
被害者の声【思考】は初めの6か月間は聞えてなかった
６か月過ぎたころから被害者の思考が被害者自身で聞こえるようになった

被害者に話しかけている加害者側の正体不明ブレインマシンインターフェイスはどこにあるのだろうか?
被害者側の思考が漏れているのなら周囲の者は電磁波で夜も眠らされていなかったことや昼間横やりを入れているのは周知の事実
これから考えて被害者の思考のみが持てていると電磁波攻撃をしている者は被害者が嫌いこの条件がそろえば被害者に対して罵声を浴びせる被害者周囲者が出現する

被害者を見る限りそのような罵声を浴びせる者が出現しないということは
正体不明ボイス・トォ・スカルをしている者の思考はどこに漏れているのでしょうか?
また周囲の者も正体不明ボイス・トォ・スカル側についたものはどこに思考が漏れているのでしょうか?

等いろいろなパターンを考えましょう

ボイス・トォ・スカルで話していたホワイトリストとブラックリストこれが重要な意味を持っていると思われる
現実的に騒がなければ被害者には何も起きていない・・・各加害者が?一番聞かれると困る者に聞かせているというのも意味深です
325 名前：デフォルトの名無しさん mailto:sage [2024/06/23(日) 21:00:39.70 ID:GCEM9Zx1.net]: Rustツアー
https://tourofrust.com/00_ja.html

説明が簡潔すぎてモヤモヤが増えていくばかり。
しかも終盤は翻訳されていない。
326 名前：デフォルトの名無しさん mailto:sage [2024/06/23(日) 22:32:11.71 ID:CiIX8R/B.net]: >>318
翻訳が進んでないのはともかくとして、説明が簡潔なのはそういうもんだわ。
チュートリアルでもつっかえるやつはいっぱいいるのに雑なツアーだけで理解できるわけないだろ。
複雑なところに立ち入る前に概略を見るってのと
それをすぐさま実行して確かめれらる環境がくっついてるってのがコンセプトなので
細かいことは The Rust Programming Language を見るのが前提。

こういった種類の学習は各項目を完璧に理解してから次の項目に進むってのは出来ない。
色んな言語機能は絡み合っていて綺麗な順番には出来ない。
全体を大雑把につかんでから解像度を高めていく形になる。
その一番最初のおおざっぱなところを担当する形の資料ってこと。
327 名前：デフォルトの名無しさん mailto:sage [2024/06/23(日) 22:46:50.25 ID:cgFz9E69.net]: C言語と関数型言語とあと何かモダンな言語の三様な言語を使える程度の知識経験があればRustはすらすら学習できるけど
それらのうち何らか知識が抜けているとその言語間での汎用的な知識も新たに学習することになるからちょっと大変になるようだね
328 名前：デフォルトの名無しさん [2024/06/23(日) 23:42:57.08 ID:iAmtDmVE.net]: >>316
そこは理解してる。
んで、Rustのfor_eachはenamerateさえすればindex使えるし、出力も出来る。

そこがC#のForEach場合、そもそもindexが使えないので一旦indexを使えるSelect & ToListを挟むことになる。

出力を考えなければ不便はないけど、出力を考えたとたんにSelect & ToListが付いてくる。

この辺は将来のバージョンに期待かな。
329 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 01:22:36.88 ID:xscSUycb.net]: >>321
理解してないでしょ

Enumerable.Range(7, 10).WithIndex().ForEach(x => {
var (index, value) = x;
Console.WriteLine($"{index}: {value}");
});

https://dotnetfiddle.net/aJJwdY
330 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 01:27:35.74 ID:xscSUycb.net]: .NET9でEnumerable.Indexという名前でenumerate相当が追加されるから拡張メソッドも不要になる
https://github.com/dotnet/runtime/blob/main/src/libraries/System.Linq/src/System/Linq/Index.cs

foreach (var (index, value) in items.Select((x, i) => (i, x)))が
foreach (var (index, value) in items.Index())になる
331 名前：デフォルトの名無しさん [2024/06/24(月) 04:37:42.69 ID:De91wzz6.net]: >>322
おお…。
確かに理解してませんでした。

ちなみに、私もその後何とかSelect内で出力を出来ないか思考錯誤したら出来たのですが、「違う。そうじゃない」な結果に＾＾；

File.ReadAllLines(fileName).Select((line, i) =>
{
Console.WriteLine($"{i + 1,2}:{line}");
return 0;
});
332 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 04:51:37.13 ID:odZr3Fxa.net]: Ruby なら、

p ary = ( 7...10 ).each_with_index.map{ |val, idx| [ idx, val ] }

#=> [ [0, 7], [1, 8], [2, 9] ]
333 名前：デフォルトの名無しさん [2024/06/24(月) 04:56:53.14 ID:De91wzz6.net]: 理解していないと思ったら、ReadAllLines(fileName)にはWithIndexなるメソッド無かったなり…。
騙されたなり…orz
334 名前：デフォルトの名無しさん [2024/06/24(月) 04:58:38.37 ID:oysLv6Xd.net]: >>325
死ね
335 名前：デフォルトの名無しさん [2024/06/24(月) 07:45:03.03 ID:m0RxboDo.net]: if や case や match やテーブル参照は使わないで
(出来れば四則演算のみがベストアンサー)
変換前→変換後
1→2
2→1
3→3
4→10
6→4
8→8
10→6
を行う関数を造ってください

さらにその逆関数を造ってください
336 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 09:09:09.41 ID:sUiNH5u5.net]: >>328
六次式でいいなら一瞬でできるでしょ
337 名前：デフォルトの名無しさん [2024/06/24(月) 10:35:24.72 ID:DSxd+1cL.net]: 統合失調症 100人い１人
本当に音波電磁波攻撃だった場合
統合失調症の寿命は
338 名前：短いからして殺害されている トロッコ問題にあてはめると Aの線路に電磁波攻撃をしている者が100人いる Bの線路に被害者が１人いる トロッコに乗っている者も第三者 切り替えポイントに第３者がいる 間違いなく選んだ方の線路の者は全員死亡する あなたはどちらを助けますか? []: [ここ壊れてます]
339 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 12:53:49.42 ID:JonISmvT.net]: 少なくとも >>330 さんを助ける人は一人もいない

>>329
なるほど
340 名前：デフォルトの名無しさん [2024/06/24(月) 16:09:25.85 ID:5PR+5FBR.net]: >>320
結局c++やってないと無理な気はするけどね。
c++は確かに建て増しでグダグダではあるんだが、
書き方の変遷をそのまま引き継いでるから、学習過程でその書き方を変遷させる過程を色々ビルドしながら
できるのはまあわかりやすくはあるんだわ。
341 名前：デフォルトの名無しさん [2024/06/24(月) 16:17:05.11 ID:jX1oxSab.net]: >>328
長くなるので最初の3つの部分だけで規則性を書くと、
1→2
2→1
3→3
342 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 16:21:31.19 ID:jX1oxSab.net]: >>333
//1→2
//2→1
//3→3
(1) 四則演算のみ:
y=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
規則は、y0*(x-x1)(x-x2)のようなパターンを
サイクリック(循環的)に繰り返す。

(2)三項演算子、その1
y=x==1?2:(x==2?1:(x==3?3:0));

(3)三項演算子、その2
y= (x==1?2:0) + (x==2?1:0) + (x==3?3:0);
343 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 16:28:01.78 ID:MN5H+Gdl.net]: スレチなのでよそでやって下さい
344 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 17:42:58.06 ID:Uuc2YNAP.net]: >>328
const INPUT: &str = "
1→2
2→1
3→3
4→10
6→4
8→8
10→6
";

fn parse(s: &str) -> Vec<(i32, i32)> {
　s.lines().filter_map(|line| {
　　line.split('→')
　　　.map(str::parse::<i32>)
　　　.collect::<Result<Vec<_>, _>>()
　　　.ok()
　　　.and_then(|v| (v.len() == 2).then(|| (v[0], v[1])))
　})
　.collect::<Vec<_>>()
}

fn make_f(v: &[(i32, i32)]) -> impl Fn(i32) -> i32 + '_ {
　move |x| {
　　v.iter().enumerate().map(|(i, (in1, out))| {
　　　v.iter().enumerate().filter_map(|(j, (in2, _))| (i != j).then(|| x - in2)).product::<i32>() /
　　　v.iter().enumerate().filter_map(|(j, (in2, _))| (i != j).then(|| in1 - in2)).product::<i32>() * out
　　})
　　.sum()
　}
}
345 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 17:43:39.86 ID:Uuc2YNAP.net]: >>336

fn main() {
　let v = parse(INPUT);
　let f = make_f(&v);
　for (input, output) in &v {
　　let calc_output = f(*input);
　　println!("{input} -> {calc_output}");
　　assert_eq!(calc_output, *output);
　}
}

結果
1 -> 2
2 -> 1
3 -> 3
4 -> 10
6 -> 4
8 -> 8
10 -> 6
346 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 18:41:27.02 ID:jX1oxSab.net]: >>334
>y=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
間違ったわ。
多分、
y=1*(x-2)(x-3)-1*(x-1)(x-3)+3/2*(x-1)(x-2);
だと思うわ。
理由は大体分かると思うけど。
347 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 18:41:27.42 ID:jX1oxSab.net]: >>334
>y=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
間違ったわ。
多分、
y=1*(x-2)(x-3)-1*(x-1)(x-3)+3/2*(x-1)(x-2);
だと思うわ。
理由は大体分かると思うけど。
348 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 18:44:46.10 ID:jX1oxSab.net]: 一般的には、次のように書けると思うわ:
a=2*(x-2)(x-3)+1*(x-1)(x-3)+3*(x-1)(x-2);
b=(x-2)(x-3)+(x-1)(x-3)+(x-1)(x-2);
y=a/b;
349 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 19:35:34.10 ID:maSlaTHT.net]: >>340
合っているかどうか以前に
プログラムコードで回答しないとスレ違い
具体的な数値例が式やコードに含まれるのは望ましくない
出来上がった関数の動作検算の時に具体的な数値例を用いる
350 名前：デフォルトの名無しさん mailto:sage [2024/06/24(月) 23:33:41.46 ID:FIb4AZ4T.net]: >>328-329
なんかダサい
https://paiza.io/projects/uc8gH6yNWCWKdQSYtqNREg
pub fn f(x: i32) -> i32
351 名前：{ ( -2413f64*(x.pow(6) as f64)/120960f64 +739f64*(x.pow(5) as f64)/1260f64 -157991f64*(x.pow(4) as f64)/24192f64 +69551f64*(x.pow(3) as f64)/2016f64 -2691673f64*(x.pow(2) as f64)/30240f64 +88679f64*(x as f64)/840f64 -905f64/21f64 +0.5) as i32 } pub fn g(y: i32) -> i32 { ( 13f64*(y.pow(6) as f64)/120960f64 -(y.pow(5) as f64)/315f64 +1415f64*(y.pow(4) as f64)/24192f64 -1511f64*(y.pow(3) as f64)/2016f64 +144793f64*(y.pow(2) as f64)/30240f64 -3053f64*(y as f64)/280f64 +185f64/21f64 +0.5) as i32 } pub fn main() { let a = vec![(1, 2), (2, 1), (3, 3), (4, 10), (6, 4), (8, 8), (10, 6)]; for (x, _y) in &a { println!("{}, {}", x, f(*x)); } for (_x, y) in &a { println!("{}, {}", y, g(*y)); } } []: [ここ壊れてます]
352 名前：デフォルトの名無しさん [2024/06/24(月) 23:39:26.44 ID:FIb4AZ4T.net]: 係数はこっちで求めたでござる
https://paiza.io/projects/YvPFB5g4cCOtCXz1wpA86g
import sys, os
from functools import reduce
import sympy as sy

def lc(a):
x, y = sy.symbols('x y')
p = 0
for i, (c, d) in enumerate(a):
g = reduce(lambda s, t: (t[0], (s[1][0] * (1 if t[0] == i else (x - t[1][0])), 0)), enumerate(a), (-1, (1, 0)))
f = g[1][0]
p += d * f / f.subs(x, c)
print(p)
print(p.expand())
for c, d in a:
print(p.subs(x, c), p.subs(x, c) == d)

if __name__ == '__main__':
lc([(1, 2), (2, 1), (3, 3), (4, 10), (6, 4), (8, 8), (10, 6)])
lc([(2, 1), (1, 2), (3, 3), (10, 4), (4, 6), (8, 8), (6, 10)])
353 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 01:47:22.24 ID:SRTwQJBb.net]: 1～10は4bitに収まるから64bitのシフト演算と論理積（&）がOKなら簡単なんだけどな
やることはテーブル参照と変わらんけど
354 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 02:44:46.88 ID:MBITUZQb.net]: >>332
Rustを習得する上でC++の知識は不要
Cでの基礎知識(ポインタ、スタック、ヒープ)しか必要としない

>>343
ここはRustのスレだ
355 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 05:16:25.10 ID:6VG6SXsU.net]: >>342
6次式を使う場合それを展開することに意味があると思えないから展開前の>>336でいいんじゃない？
356 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 07:25:12.24 ID:H43UHQbv.net]: >>346
ほぼ定数になる部分まで
実行時に二重ループで毎回計算してるのは効率悪いと思う
357 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 07:47:56.32 ID:hXiD4muz.net]: >>345
っ move semantics
っ RAII
っ SmartPointer(Rc)
358 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 08:03:22.73 ID:ZJws2e45.net]: >>348
そりゃすでにC++を知っているならそのへんの知識が流用できて楽だけど
新たに学ぶならわざわざC++を経由する必要なくね？
特にmoveとか明らかにC++のほうが複雑だし
359 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 08:54:41.29 ID:Lgitw8zf.net]: お題スレが機能しなくなってゴミがあふれてきてんのかこれ？
360 名前：デフォルトの名無しさん [2024/06/25(火) 09:00:44.98 ID:ZTu14b8J.net]: >>349
c++通らなきゃなんでこんなめんどいことするか理解できんだろ
361 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 09:03:31.00 ID:9+k+boDP.net]: 「アセンブラ知らずにCって理解できるものなのか？」
↓
「C++の方が普通。Cは専門家向け」
↓
「いきなりRust」
362 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 09:25:46.54 ID:eEyTJz94.net]: オレはPHPからRustに移行したよ
actix web使ってる
速さには感激してる

戸惑うのは謎のワーニングが出る時かな
mut付けてないのにmut付けるなってワーニング出たりする
cargo cleanとかすれば消えるんだけど
363 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 09:32:01.85 ID:GyGy4ZSw.net]: >>351
Cでmalloc/free手書きしたりSEGV起こすだけで十分理解できると思うけどなぁ
C++じゃないとダメなのってどのへん？
364 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 10:36:22.38 ID:398g93Vj.net]: >>348
その3つはどの言語から来ても簡単にすんなり理解できるでしょ

>>353
PHPから来た人はジェネリクスはすんなり理解できるものなの？
365 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 11:03:26.31 ID:eEyTJz94.net]: >>355
ジェネリクスが特段わかりずらいとは思わなかった
それより型があいまいなPHPから移行すると型定義したくてうずうずする
ちゃんと型定義したかったんだわ
366 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 11:48:25.07 ID:EN7MeMPi.net]: C++ を知っていると Rust がわかりやすいというよりも有難みを感じやすいとは思う。
なんだかんだで Rust は面倒くさいしそれなりに学習曲線の急上昇もあるのは本当だけど、
それでもなお Rust が良いと思えるのは C++ の駄目な部分についての反省が入ってるから。

C++ 的なものが必要な場面で C++ より上手くやるものという感覚で捉えてる。
367 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 12:43:05.46 ID:qH1sgo3/.net]: 「Rustを学ぶためにC++を学ぶ必要があるか(学ぶといいか)」も定期的に沸くな

何度も見てて思うのが
「あなたはRustを学ぶ前にC++を学んでいたか」とYes/Noが一致して、平行線にしかならない議論なのでは
368 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 13:05:45.82 ID:ZtCD4zFU.net]: フランス語を学ぶときに英語を知ってる必要があるか(學ぶといいか)を考えれば良い
日本語←→フランス語だけ教わりたいのに英語學ぶ必要は無い
369 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 15:05:50.09 ID:UfTXO4rA.net]: Rustを学ぶ前に他言語を学ぶ必要は無い。

しかしプログラム自体の経験が浅いのなら、絶壁の学習曲線に挫折する可能性が高い。そういう初学者はRusuではなく、とりあえずは動くところまで持っていきやすい言語を使って勉強したほうがいい。
370 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 15:23:35.53 ID:bjcoCLHQ.net]: C++を経由しないでRustを使えてる人たちがたくさんいることから
C++が不要言語であることは間違いない
371 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 15:29:24.75 ID:ZtCD4zFU.net]: >とりあえずは動くところまで持っていきやすい言語

Rustも変な事しなければとりあえずは動く
C/C++みたいに一見動いてるフリしてメモリ壊してたりに気付かない方が有害
372 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 16:22:38.23 ID:EN7MeMPi.net]: それはプログラミングに慣れてるから言えることで、
エラーになってくれることが心底から有難いことだと思えるのは
エラーにならずにぶっ壊れる体験を通してじゃないと無理だよ。

結果的にわかりやすいかどうかの話じゃなくて
学習する当人がちゃんと納得して学習し続けられるかというモチベーションの話としてね。
373 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 16:57:26.38 ID:bjcoCLHQ.net]: Cでmalloc/free面倒とか忘れたとか解放したのにポインタ残っていて使っちゃったとか体験しておいたほうがよいかもしれないが
C++は不要
374 名前：デフォルトの名無しさん [2024/06/25(火) 17:23:57.01 ID:jUYULW90.net]: >>363
つまり最初はPerlが良いってことか
375 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 17:55:00.58 ID:EN7MeMPi.net]: 初心者レベルだと C/C++ もRust も向いてないって話
376 名前：デフォルトの名無しさん [2024/06/25(火) 19:32:04.37 ID:l0yCAl6v.net]: そう言えばHaskell難しい言うやつも似たようなこと言ってたな。
そんなに難しいと感じてなかったから不思議だったんだが、
自分でバグ作っておいて言語が難しいとか言うなよ…。
377 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 20:03:41.12 ID:qH1sgo3/.net]: ID:ZtCD4zFU
ID:bjcoCLHQ
378 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 20:13:30.50 ID:urOX5j9P.net]: 関数型言語を使ってるとRustの理解が少し早くなるよ
特にHaskellを知っていればtraitの理解も早いね
しかしRustを学ぶために関数型言語を知っている必要はないんだよな
同様にC++も知っている必要はない
379 名前：デフォルトの名無しさん [2024/06/25(火) 22:48:01.04 ID:3rDdWdgz.net]: Erlang使ってて良かったと思った
380 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 23:04:44.45 ID:8sxbkiyD.net]: バレおじw
381 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 23:30:51.26 ID:oKw2Pfcc.net]: >>347
展開しないほうがよい

展開する時も二重ループは発生するだけでなく単なる計算より重い
さらに本来は回避できる浮動小数点を使わざるを得なくなる
そして>>342のコードをその例のような静的ではなく問題入力値に応じて動的に作り出さなければならない

一方で展開しないならばRustコード数行だけで済み任意の問題に対応できる
割り算部分も0/N=0かN/N=1だけなので整数で済む
382 名前：デフォルトの名無しさん mailto:sage [2024/06/25(火) 23:49:25.06 ID:ThxORcgc.net]: >>369
>特にHaskellを知っていればtraitの理解も早いね
これには全く同意できない
type classというかHaskellとはやり方もできることも違いすぎるから
そもそも何の事前知識なくてもtraitは容易に理解できるでしょ
383 名前：デフォルトの名無しさん [2024/06/26(水) 08:25:01.52 ID:egC8x8gn.net]: 神精霊絶大なエネルギーを使用可能
幽霊人間を疲れさせるや一時操作可能
①エネルギーの貯蔵の仕方は➁そのエネルギーの発生方法は③そのエネルギーを貯蔵する方法は④それだけのエネルギーの物体を科学で観測不能はなぜ

6G通信に使われるテラヘルツ帯の電波、脳細胞の成長を促進
2022/08/16
タンパク質の操作／マイクロ波等の照射が記憶に影響
2008/11/01
男性の精子の減少、携帯電話の使用と関係か最新研究
2023/11/02
統合失調症.発達障害.各身体症状など国力低下
人為的で身体攻撃
威力を測定すれば判明するのにテロリストを野放し

全ての精神病
①　英キングス・カレッジ・ロンドンをはじめとするグループは、人間の脳内で発現している古代ウイルス由来のDNA配列を調べ、それがうつ病・統合失調症・双極性障害といった主要な精神疾患のなりやすさと関係していることを明らかにした。
➁九大、後の出来事が直前の出来事に錯覚を起こさせる脳の仕組みの一端を解明
2024/06/05
④幼児期の脳活動から18歳時点でのIQを予測できるという研究結果
2023/09/09
⑤3歳までに脳は形成される
⑥統合失調症などの患者に幻覚や妄想を引き起こす脳のネットワークがAIを使った研究で明らか

1立方ミリメートルの脳の断片をハーバード大学とGoogleの研究者がナノメートル単位で3Dマッピングすることに成功
2024年05月10日
※MRIで物理的に神経の接続問題観測可能

嘘つきの知的障碍者と精神障碍者や認知症の者発見

◇電磁波攻撃はあるとないどの思考【組織】の者が話しているのかな
マイクロ波聴覚効果やボイス・トォ・スカル発見可能
電磁波している者守りたいもの守りたくないものの判別
384 名前：方法は各対象者の将来で名よある地位やよい未来の映像と悪い未来の映像を見てもらえば副交感神経と交感神経の差と脳波パターンをみたら判明する []: [ここ壊れてます]
385 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 12:30:12.07 ID:j6fp+f8B.net]: >>372
>割り算部分も0/N=0かN/N=1だけなので整数で済む
そうだね
この問題の本質はそこだと思うけどそれ言い出すとif使わない理由が無いな
386 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 12:31:27.14 ID:j6fp+f8B.net]: >>373
事前にやるならNimの方が良いよ
387 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 13:01:41.83 ID:eR4cI6Xf.net]: Rustを学ぶ前に他の言語を学ぶ必要はないけど
全くプログラミング言語を知らないならシンプルで学習例も多いC言語一択だね
ポインタとヒープの扱いまで学べたらたらC言語を忘れてRustへ
388 名前：デフォルトの名無しさん [2024/06/26(水) 14:31:44.00 ID:uKek7pO0.net]: デストラクタの動きを知らないで本当にrustできんの？って思うけど
389 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 14:43:55.70 ID:eR4cI6Xf.net]: スコープを抜けた時にデストラクタが自動的に呼ばれる
それだけ
予備知識を必要としない
390 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 14:54:42.66 ID:j6fp+f8B.net]: Rustのデストラクタの描き方ってなんであんなんなん
391 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 15:00:49.20 ID:KtPyzxFO.net]: C書くしかない時代だったからC勉強できたけど
Rustがある時代に純粋な教養としてC勉強なんて苦行できないだろ
修行僧かよ
392 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 15:13:01.92 ID:UcL9V/nx.net]: 最近気付いたんだけどもしかしてRustの所有権って2通りの意味がある？
393 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 17:42:24.19 ID:AVbFTHWJ.net]: >>382
そのココロは？
394 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 18:05:02.22 ID:tR/OTOKs.net]: >>378
それってc＋＋学ぶときも一緒じゃない？
395 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 20:50:33.32 ID:mzS1vumz.net]: >>382
Rustを学ぶ上で所有権は忘れた方がいい
実はRustは非常にシンプルで
値をmoveして用いるか参照して用いるかしかない
(ただしCopy実装型はmoveの代わりにcopy)
値はmoveされないままスコープが尽きると消える
消える直前にデストラクタが呼ばれる
以上たったこれだけだ
396 名前：デフォルトの名無しさん [2024/06/26(水) 23:00:32.38 ID:GOea043w.net]: >>381
苦行はごちゃごちゃして煩わしい記述を強要されるRustだろ。fnだのmutだの略語が多く
殺伐としているし、記号の使い方なども含めて如何にもギークが作ったというような
美的感覚が欠如した野暮ったいコードを書き連ねるのはおぞましい。

Cと違って新しいSwiftはRustに機能的に近いが、Rustよりずっと洗練されている。
397 名前：デフォルトの名無しさん mailto:sage [2024/06/26(水) 23:26:44.75 ID:skjSHmL1.net]: Rust言語を知らないから見た目のキーワード批判しかできないのだ
398 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 04:20:04.01 ID:nawTLqWn.net]: スタックは早くてヒープは遅い、みたいな話よく聞くんだけど、
具体的に何が早い/遅いの？
399 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 04:33:33.49 ID:TDzAch9x.net]: >>388
自分でヒープメモリ管理部分を書いてみるとよくわかる
ヒープでメモリ確保したり解放したりするのは色んな処理が入って非常に遅い
スタック上ならそのコストはない
関数に入る＆抜けるときにスタックフレームを指してるレジスタの値を変えるだけ

というのに加えて
CPUの多段メモリキャッシュ機構での速さが桁が変わってくる
スタックフレーム上なら常にアクセスしていてキャッシュに載るから超速い
400 名前：デフォルトの名無しさん [2024/06/27(木) 07:18:32.22 ID:CXekxx/V.net]: >>386
mutが煩わしい言うてる時点で関数型プログラミングをまともに出来てないな。
今までの副作用だらけの言語だとマルチスレッドプログラミングが上手く出来ないから関数型プログラミングを取り込んだというのに。

Rustでごちゃごちゃしてると感じるならHaskellにおいで。
forやifと書くことすら煩わしく感じるくらいシンプルだよ。
401 名前：デフォルトの名無しさん [2024/06/27(木) 08:56:33.16 ID:ozUuBzDI.net]: Swift、よく知らないんだよなあ
Appleの囲い込み言語という時点でもう勉強する気になれない
402 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 09:08:39.14 ID:AKJ8/1zo.net]: C++ でも変更なしのときに const を付けるんじゃなくて変更ありのときに指定するほうがよかったという声は結構あるよな。
まあいまさら変更できんが。
403 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 09:50:18.20 ID:OTNDZ+yC.net]: >>372
PyO3おすすめ
404 名前：デフォルトの名無しさん [2024/06/27(木) 10:07:28.99 ID:OTNDZ+yC.net]: >美的感覚が欠如した野暮ったいコード

禿しく同意
405 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 10:21:46.91 ID:nawTLqWn.net]: >>389
キャッシュに乗るという前提なら、
確保・解放が遅いだけでアクセス速度とかは変わらないってことでOK？

キャッシュに乗る確率とかもスタックとヒープでやっぱちがうんかな
406 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 10:30:52.47 ID:OTNDZ+yC.net]: キャッシュに載ったらアクセス速度変わるやろ
407 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 10:33:46.61 ID:xhKCtT/7.net]: そりゃ、キャッシュ・イズ・キングと言うぐらいだからな
408 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 11:05:58.76 ID:AKJ8/1zo.net]: >>395
キャッシュに乗りやすいというのはアクセスに局所性があるということ。
関数自体が小さくてすぐ終わるなら普通はスタックのほうが以前と近い場所にアクセスすることになる。
409 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 11:20:07.91 ID:veLj9zg3.net]: よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
「そんなわけないだろ」って思うんだけど
410 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 11:56:53.85 ID:TDzAch9x.net]: >>395
スタックフレーム同士も連続しているし
レジスタ退避でアクセスしているし
他のローカル変数もスタック上にありアクセスしているから
スタック上に確保すればキャッシュ上にある
411 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:00:05.74 ID:TDzAch9x.net]: >>399
関数が値を返す場合にサイズが小さければレジスタで返す
サイズが大きい場合は呼び出し元のスタックフレームに領域を確保してそこへ直接書き込んでいる
つまり暗に可変参照を渡す最適化が行われている
それはサイズの大きい値を返す関数呼び出しが多段でも同じなので一番最初の関数のスタックフレームに直接書き込まれる
412 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:27:57.71 ID:OTNDZ+yC.net]: >>399
>「そんなわけないだろ」
その感覚は正しい
Rustを広めたいために勢い余ってデマを流してる香具師が一定数いる

>>401 が正しい
413 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:45:47.11 ID:VTKaeii9.net]: >>399
>よくわかんないんだけどスタック上に確保したメモリの所有権を外に移して関数は終了してスタックが縮んじゃうとかさ
これ自体なにを言いたいのかよくわからんけど
その前にそんなこと言ってるやつおる？

>>400
>スタック上に確保すればキャッシュ上にある
キャッシュから追い出される状況もあるよね
414 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 12:53:21.92 ID:TDzAch9x.net]: >>402
いや>>399の話も正しいんだよ
重要なのはRust上の概念とその実現方法(実装)とその最適化の3つは当然異なるということ

所有権を移すとはmoveという概念であって
moveの実装はコピー(してコピー元を使わない)
ただし無駄なコピーは最適化で消える
例えば大きなサイズの構造体を関数が返す場合は呼び出し元の関数のスタックフレーム上に直接書き込まれることで無駄なコピーが発生しない
415 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 13:06:53.73 ID:VTKaeii9.net]: それをスタックが縮むと表現してるのか
意味は分かった
416 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 13:24:58.99 ID:veLj9zg3.net]: スタックてのは関数が何段か終了して縮んだあと、また伸び直して前の伸びを上書きしちゃうでしょって話
とにかく「移動」というのが新しくて、代入の移動はわかったけど
関数呼び出しの引数も移動です、返り値も移動ですってのがどういう実装に落とされるのかまだわかってない
417 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 13:49:01.55 ID:AKJ8/1zo.net]: 低レイヤで起こってることは C と変わらん。
寿命の矛盾がないか静的な検査がクソ強いってだけだ。
418 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 15:56:45.17 ID:AKJ8/1zo.net]: スタックを伸ばすだの縮めるだのいうのはメモリのとある番地に実際のメモリを割り当てたり切り離したりすること。
スタックが足りなくなってきたら連続するアドレスのところに実メモリを割り当てるのがスタックを伸ばすってこと。
普通の使い方をしていたらスタック領域を縮めることはあんまりない。
スタックがあるところまで伸びたということはもう一度そこまで伸びる可能性が高いので回収してまた割り当ててをするよりは割り当てっぱなしにしたほうが良いという設計思想になってるので全体のメモリが足りている限りスタックが浅いところまで戻ってきても実メモリを回収しないというのが現代的な OS。
逆に言えば全体のメモリが足りなくなってきたら回収することもあるんだけど。

素人感覚だとメモリをなるべく空くようにするのが「メモリの無駄を防ぐ」という意識の人がいるんだけど、存在するメモリが使われないままになってるほうがもったいないんだ。

それとたとえば Linux だとスタックの大きさは 8MB が上限というのがデフォ。
これは OS 側の設定なのでアプリケーション側では (OS の設定をいじる権限がない限りは) どうにもできない。
8MB ってめちゃくちゃ少ないように感じるかもしれないけどだいたいこんなもんで足りちゃうんだよ。
419 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 16:39:29.50 ID:EaS5WQGi.net]: >>406の書いてる「縮む」はVecで言うところのcapacityじゃなくてlenっぽくない？
ムーブとの関連がよくわからんけど
420 名前：デフォルトの名無しさん [2024/06/27(木) 17:46:10.67 ID:6+Lg0PcZ.net]: >>407
ですな
421 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 17:59:42.80 ID:AKJ8/1zo.net]: 低レイヤのメモリの取り扱いモデルが確立している高級言語が C/C++ くらいしかなくて、 LLVM も汎用的なフレームワークのふりして思ったほど自由ではないので Rust の言語仕様が LLVM の都合に、 C/C++ の都合に引っ張られているところはまあまあある。
422 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 18:20:02.76 ID:veLj9zg3.net]: つまりC++同様、ポインタの糖衣構文としての参照？
423 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 18:50:13.20 ID:veLj9zg3.net]: あ、なるほど
&mutみたいに*mutって書けば実体を扱えるわけか
424 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 18:56:27.59 ID:RLHdjniL.net]: いつものことながら妙なこと書く人はだいたいThe Book(本物)を読んでないよな
425 名前：デフォルトの名無しさん [2024/06/27(木) 19:07:01.79 ID:inDwmtnT.net]: そんなの読むような真面目な人間は5chに来ない
426 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 20:08:52.27 ID:AKJ8/1zo.net]: >>412
まあ機械語レベルの低レイヤまでいけば参照もポインタも同じっちゃおなじだけど、構文糖だという認識は明確に誤りだ。
参照がポインタの構文糖なんて書いてあるデタラメ本で C++ を学んだのなら C++ の理解も全然できてないと思う。
または書いてないことを脳内で作り出すタイプのやつは誤った方向に邁進してどうにもならなくなったところで質問したりするから言ってることが意味不明になりやすい。
仮に(あくまでも仮にだが！)言ってる理屈自体が正しかったとしてもちゃんとした用語でいってくれないと伝わらないし、ちゃんとした用語は(一次資料に基づいた)ちゃんとした資料で学ばないと身に付かん。
427 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 22:40:30.91 ID:TDzAch9x.net]: >>406
そのmoveについてもmoveというRust上の概念の理解のみがRustを学習＆利用していく上で必要となるよ
moveによる生成コードがどのようになるかは最適化の方法の変更や進化で変わり得る話だから確定することはできず、学ぶこともできない
こんな場合に現在はたまたまこんな生成コードになっていることだけは実験などでわかるけど今後の保証はない、としか言えない
だからmoveはmoveとして理解することが唯一の正解でしょう
428 名前：デフォルトの名無しさん [2024/06/27(木) 22:43:00.49 ID:QXPbo1LF.net]: どうせChatGPTの回答を使い回してるだけだろ
429 名前：デフォルトの名無しさん [2024/06/27(木) 22:45:03.57 ID:QXPbo1LF.net]: >>416
C/C++でポインタのポインタと言わずに
ダブルポインタって言ってる香具師のことか
430 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:03:07.98 ID:TDzAch9x.net]: Rustの各概念を無理矢理なC/C++と結びつけようとしたり生成コードと対応させようとしてる人々がRustを難しいと言ってるようにみえる
そんなことをせずに各概念の理解だけに集中すればRustはシンプルに出来ていてわかりやすい言語だと理解できるよ
431 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:34:16.52 ID:AKJ8/1zo.net]: C/C++ だと抽象機械という概念を挟む形で仕様化されてる。
言語の挙動を抽象的な (架空の) 機械の動作として記述していて、それを実際の機械とどう対応させるかは知らんけど見かけ上の動作が仕様通りなら良しとする規定。
だから最適化を豪快にやっても結果が同じなら言語仕様に反しない。

で、抽象機械っていうのはある程度は現実のコンピュータを想定はしているけど細かいところは意図的にうやむやにして選択の余地を残してる。
C/C++ には言語仕様としてはスタックもヒープも存在せず書いてあるのは寿命についてのルールだけで、それをどういう形で実現するかは自由……
なんだけど現実にはスタックとヒープを使い分けるとちょうどいいような仕組みになってる。

C/C++ の言語仕様に低レイヤのメモリアクセスのことも確かに書いてあるんだ。
でもそれは抽象的な機械のことであって本物の機械のことじゃない。
でもある程度は対応しているという絶妙なバランスで成り立ってる。

Rust では言語の高レイヤの話と低レイヤの話の間を取り持つ理屈がまだ十分に整理されてないと思う。
言語の性質上、やっぱり低レイヤを全く意識しないで上手く使えるようなものでもないし、低レイヤのことを考えるのもそれなりには必要だと思う。
必要なんだけど意識的にレイヤを分けて考えられないなら混乱するのも確かなので、 (少なくとも最初は) 低レイヤのことは忘れろというのは理に適った助言だと思う。
432 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:40:56.83 ID:ZCM59EGi.net]: C/C++の方こそ誤魔化しているぜ
そのため未定義動作だらけだ

Rustはわかりやすく抽象的に明確だ
そして未定義動作もない
433 名前：デフォルトの名無しさん [2024/06/27(木) 23:46:01.41 ID:AKJ8/1zo.net]: 未定義動作の話をしてはいないよ。
低レイヤとの間をどう取り持つかの話をしてる。
434 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:53:14.85 ID:iyfRmZdF.net]: Rustは低レイヤにも対応している
高い抽象度によるプログラミングもできる
高い抽象度のプログラミングにおいて低レイヤとの対応付けは不要であってやるべきではない
435 名前：デフォルトの名無しさん mailto:sage [2024/06/27(木) 23:56:31.92 ID:lXX+GpEL.net]: オジーw
436 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:09:40.45 ID:uAgz1Jdl.net]: >>424
その論を許すなら Rust は OS やデバイスドライバを書くのには使えない言語であってよいという立場になるが、そうじゃないよね？
437 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:16:19.92 ID:hS2q8k+h.net]: >>426
なぜなの？
Rustが抽象的にプログラミングできるのも事実であるし
OSやデバイスドライバを記述できるのも事実だよ
438 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:20:27.61 ID:uAgz1Jdl.net]: >>427
低レイヤを書くための仕様が確立していなくて今はなんとなく書けているという状態を「できる」と称していいならそうだね。
439 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:28:00.38 ID:UvqDoogo.net]: >>428
うーん
Rustに何か欠けているわけではなく
実用的に問題なく機能している状況で
言い掛
440 名前：かりをつけてるだけにみえるけどどうよ []: [ここ壊れてます]
441 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:48:52.30 ID:uAgz1Jdl.net]: >>429
実用的に問題があって、機能できていない。
Rust の仕様に明るくて低レイヤのメカニズムに明るくても Rust で OS は書けないから。
現状では Rust の実装に明るいという要素が求められていて、ある程度はそういうものかもしれないけど仕様 (というか文書化というべきかな) の明確化が十分とは言えない。
442 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 00:57:19.20 ID:UvqDoogo.net]: >>430
本気で言ってるのかなあ
デバイスドライバはRust製に置き換えられたよ
OSもRustで新たに作られて機能することも判明してるけど
既存のOSは書き換えコストの問題だから別問題だね
443 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 01:04:07.98 ID:0ko0Zb9B.net]: そういえばRedoxの開発は今どうなってるんだろ
444 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 01:21:44.32 ID:uAgz1Jdl.net]: >>431
これからやる人に対して説明できる形になってないという話をしてる。
出来てるから出来るんだというのは何の根拠にもならんよ。
出来るようになるための道筋が確立しているかどうかの話なんだ。
445 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 01:57:43.66 ID:/H5n5ha9.net]: 流れを切って申し訳ないんだけど
Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる?
まだ一部の物好きが書いてるだけ?
446 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 02:39:42.33 ID:OzTZZFgl.net]: 自分

Rustってディープラーニングのプログラムを作るのに実用的な段階に来てる?
まだ一部の物好きが書いてるだけ?

Copilot

Rustでディープラーニングのプログラムを作ることは可能ですが、まだ一部のエンジニアが実験的に取り組んでいる段階と言えます。具体的には、『ゼロから作るDeep Learning』の内容をRustで実装する試みや、Deep LearningのフレームワークDeZeroをRustで実装する試みなどがあります。

これらの試みは、Pythonで書かれたディープラーニングのコードをRustに翻訳し、Rustの学習やディープラーニングの理解を深めるためのものです。しかし、これらの実装はあくまで個々のエンジニアの学習目的で行われており、一般的なディープラーニングの実装にRustが広く使われているわけではありません。

Rustはパフォーマンスが高く、メモリ安全な言語であるため、ディープラーニングの実装にも適していると言えます。しかし、Pythonのように豊富なディープラーニングライブラリが存在しないため、現状ではディープラーニングの実装にはPythonが主に使われています。

Rustでのディープラーニングの実装が一般的になるかどうかは、今後のRustコミュニティの活動やディープラーニングの研究動向によるところが大きいでしょう。
447 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 02:47:01.21 ID:/H5n5ha9.net]: >>435
さっそくの返信ありがとうございます

> 今後のRustコミュニティの活動やディープラーニングの研究動向

がどうなってるかを聞きたかったんですがどんな感じですか?
libtorchバインディングのtorch-rsや
ほぼ純Rust製のcandleが出てきたのはわかったんですが
まだ周辺ライブラリが足りない感じです?
448 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 03:31:36.21 ID:OzTZZFgl.net]: 少なくとも俺よりはAIの方が物知りだから自分でAIに聞いた方がいいと思う
449 名前： 警備員[Lv.22] mailto:sage釣 [2024/06/28(金) 03:44:03.44 ID:J0YB6tE5.net]: 論文の検証を論文と異なる言語ではしないでしょぅ
NCNNやDarkNetを超えるエンジンがあるわけではなし
450 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 05:55:26.25 ID:OzTZZFgl.net]: >>417
関数の引数にオブジェクト（Copy型でない型）を渡す際は参照渡しが基本で、
うっかり所有物を引数として渡すと所有権ごと関数の向こうへ移動してしまって二度と戻って来ない
これは逆に、関数が何らかの実体を返り値として返す際には便利

とまあネチネチ考えてればわかってくるもんだよ
451 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 07:54:27.71 ID:diDidYCE.net]: >>422
unsafeを無視しちゃいかんよ。
452 名前：デフォルトの名無しさん [2024/06/28(金) 09:41:44.10 ID:RD8xbJnt.net]: 型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ
453 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 09:45:48.57 ID:uAgz1Jdl.net]: 仕組みがまだ確立してなくて試行錯誤があるなら型で制約しまくるのは面倒なだけだけどもうそういう段階じゃないのなら型で固めたほうが (使い方の間違いが検出されやすいので) 生産性高いよ。
454 名前：デフォルトの名無しさん [2024/06/28(金) 12:27:02.70 ID:4Cbqp0xY.net]: >>441
C++/C#/Javaとの比較はともかく、LLとの比較は目指すところが違うでしょ。
Rustは組み込みやOSまでカバーする言語。

医療用機器とか、自動車とか、命に関わるような分野でバグを入れないための言語なんだから。

金融も同じようなものだけど、そっちはOCamlの実績（みずほ）があるのでRustである必要は必ずしもは無い。
455 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 13:07:10.53 ID:gx/r5usH.net]: LLとかいう死語を使ってるのは複オジだけだぞ
456 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 13:32:56.61 ID:3PtwFBGo.net]: >>441
ささっと数行書くスクリプトでなければ静的型付け言語が生産性高いよ
457 名前：デフォルトの名無しさん [2024/06/28(金) 17:07:56.21 ID:v8X9ZSBd.net]: うい。４０のおっさんよん(^_-)

まあ、プロトタイプは動的型言語で作って、本番のコードは静的型言語で作るなんて常識なんだから、若い人じゃなければ

> 型がガチガチの言語でdeepnetの実装するのは面倒な割に生産性薄いわ

何てこと書かないわな…。
458 名前：デフォルトの名無しさん [2024/06/28(金) 18:51:50.94 ID:y+eGYcxn.net]: 今のご時世にプロトタイプは動的言語とか言ってるのは頭の硬いジジイか、ジジイの本でしか勉強出来ない馬鹿がほとんどなんだよなあ
459 名前：デフォルトの名無しさん [2024/06/28(金) 19:09:29.56 ID:v8X9ZSBd.net]: 出来る人ならそれで良いし、それで>>441の言うように生産性が低いと感じないなら全然かまわない。

馬鹿馬鹿言うけど、そういう馬鹿にも作らせないといけないし、それでも作れない救えない奴はリストラするしか道が無い。
460 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 19:58:03.61 ID:pImSoiYg.net]: 動的型でプロトは結局本番で書き直す時間など取れないから机上の空論ってのが最近の認識では
最初から静的型にするか、どうしようもなくなるまで動的型で耐えるかの2択じゃないかな
まぁたいていのスタートアップは耐えられなくなる前に潰れるからそれを見越して動的型というのはありだと思うが
461 名前：デフォルトの名無しさん mailto:sage [2024/06/28(金) 20:05:28.17 ID:3PtwFBGo.net]: スタートアップ企業であろうと
動的型付け言語を使うのは開発効率が悪い
462 名前：デフォルトの名無しさん [2024/06/28(金) 20:36:15.04 ID:v8X9ZSBd.net]: んー…。
おっさん的には関数単位でテスト出来るかどうかが問題であって、プロトタイプは動的か静的かの問題じゃない気がするな。

最近は静的型言語でもインタラクティブシェル（略語忘れた)のインタプリタで関数単位でプロトタイプ作ってテストして、上手くいけばビルドって流れだし。

そういうのが無い言語は今でもプロトタイプは動的言語で作って…ないわｗ

場合によるな。
すでに作り方を知ってたらいきなり静的型言語で書くし、何か思いついたけど確信が持てない。みたいな時(試行錯誤が予想される)は動的型言語でプロトタイプ書いてるかな。
(静的型言語にインタラクティブシェルが無い時)
463 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 03:44:24.89 ID:pz5Aaald.net]: Rustのメモリモデル
https://doc.rust-lang.org/reference/memory-model.html
464 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 09:52:45.11 ID:H9n2Ca7a.net]: 少人数で超大規模なシステムを作るのには Common Lisp が向いてるみたいな話もある (実際に使われてる) けど、それはプログラマが超人なだけじゃないのみたいな話もあってあまり一般化した話には出来んな。
465 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 10:24:54.66 ID:PsPEDCdZ.net]: 権利あるいは義務が移動することを物理メモリで説明するのは難しいが
実行時型情報みたいにいちいちメモリを消費して情報を管理すれば
物理で説明できないこともない
そのためには動的言語の知識も役に立つ
466 名前：デフォルトの名無しさん [2024/06/29(土) 11:40:57.14 ID:VzEkAlY7.net]: 実際機械学習でc++でもjavaでもほとんど使われてないってのに、やっぱ静的解析バカが多いんだなここ
467 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 12:11:39.54 ID:hrAqOO+e.net]: Pythonでも”静的解析”は普通に使ってるだろw
自分が書いてる用語くらいは学んどけよww
468 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 12:15:59.49 ID:bAOaGwrv.net]: ダックタイプあれば動的でも静的でもあんまり変わらん。ビルド時間の違いくらいか。

実装初期は設計の柔軟性を確保できればいい。まぁ、アダプタでなんとかするのが妥当なところかもしれんが。
469 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 12:40:22.21 ID:tytG9AfV.net]: オーナーシップとライフタイムの関係でGC言語なら簡単なリファクタリングがRustでは大手術が必要になることがよくある
大手術すぎて根本的なリファクタリングに着手できてない例もよく見かける

ここでいってるプロトタイプとは少し意味が違うがPython等でプロトタイプ作ってRust化する人がある一定程度いるのはプロトタイピング時にボローチェッカーで時間を浪費するよりも言語変えた方が効率がいいと考えられてるから

この辺はRustのメリットとデメリットを考えた使い分け
470 名前：デフォルトの名無しさん [2024/06/29(土) 12:42:41.17 ID:OVmXtfXA.net]: ダックタイピングがあれば良いが、Pythonのダックタイピングはライブラリの型が壊れているからダメ
あと、ダックタイピングの不満を消していくとTraitになるから出来ればTraitの方が良い
471 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 13:28:37.21 ID:7275QU0+.net]: >>458
そういうRustでのリファクタリングならば大手術にならない
メモリ保有を適切な位置に移したり分解したりするなどの単純なリファクタリングで済んでいる
それにより保守性もデバッグ効率も上がるためリファクタリングコストは誤差に等しい
仮にGC言語で書いている時でも同様でその状態は各データが複雑に絡み合っている状態なのでリファクタリングしたほうが望ましい
472 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 13:38:30.46 ID:xx5BdVU7.net]: ダックタイピングがあるってどういう状態のことだろう
473 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:06:46.53 ID:H9n2Ca7a.net]: リファクタリングの原則のひとつとして外側から見たときに変わらないというのがある。
内と外を分ける境界線がどこなのかというのは場合によるので UI レベルで同じなら良しとすることもあるけど、普通は適当なモジュール単位でやるだろう。
「変わらない」ことの保証のひとつとして型やライフタイムアノテーションは頼りになるよ。
型システムがあてにならないほどの大改革ならどうせ全部書き直しなので足を引っ張られることもない。
474 名前：デフォルトの名無しさん [2024/06/29(土) 14:24:33.15 ID:lbQtaoAJ.net]: Rustはリファクタリングには全く向いていない
475 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:31:05.74 ID:dyJ1RvLM.net]: いつも汚いコードを貼り付けてた複オジがリファクタリングは簡単などと言い張ったところで全く説得力がない
476 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:38:55.22 ID:pz5Aaald.net]: 数のイテレータで遊んで満足してる人に機械学習の文脈が理解できるわけないやん？
477 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 14:41:30.81 ID:Kxp5xIIU.net]: 掲示板に貼れる程度の内容なら
リファクタリングしても知れてるでしょ
478 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:08:40.24 ID:BT1eNZRh.net]: >>463
Rustはリファクタリングに向いている言語だよ
リファクタリングで最も重要なことはその前後で同じ機能動作が保証されることだけど
そこで静的型付け言語が有利なことは当たり前としてRustのアクセス競合排他原則がさらに大きく効いてるよ
データ書き換え中の読み取りによるバクがリファクタリングによって入り込むことも防いでくれているね
479 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:23:13.20 ID:PsPEDCdZ.net]: デジタル小作人やめるレベルの大手術ではなく
地主との関係が変わらないことを保証したいんだな
480 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:34:20.66 ID:KH8yb7Br.net]: それまで参照を持たなかった構造体にメンバとして参照を持たせると、型にジェネリックライフタイムが付いて、その型の使用箇所全部でライフタイムを書く必要がある
さらに悪いことに、実際のところこれは必要ではなく、ライフタイムを書かなくても省略されていると見なされてコンパイルが通ることもある
しかしこれでは意図通りのライフタイムになっていないことが多く、その型の使用箇所を増やしたときに初めてそのことに気づくことになる

Rust特有のリファクタリングしづらさは、あるよ
481 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 15:52:41.67 ID:jlQztVvs.net]: ライフタイム関連に限らずRustのリファクタリングは
他言語に比べて波及する範囲が大きくなりやすいんだよね
それで作業量が多いからしんどい

しんどさと難しさは必ずしもイコールではないんだけど
サクサク変更できる言語を経験してると
Rustのリファクタリング時には精神的なエネルギーが相当必要
482 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:01:57.62 ID:obFhbebh.net]: >>469
リファクタリングの作業の大きさに対して、必要なライフタイム注釈を付けるだけの些細なことが障害になったことはないな。
ライフタイム注釈が'aになるか'_になるか省略できるかは、その必要性と省略ルールに基づくだけなので、そこで問題が発生することはないだろう。
483 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:03:28.89 ID:obFhbebh.net]: >>470
Rustでは様々なことをコンパイラチェックに任せられるため、リファクタリングで最も崩れにくく、人間の負担は他より小さい。
484 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:10:10.85 ID:FxtNCeeF.net]: 糠に釘
暖簾に腕押し
複オジにRust
485 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:52:22.95 ID:KH8yb7Br.net]: >>471
「ライフタイム注釈が'aになるか'_になるか省略できるか」は、すべての使用箇所ごとに以下を検討したうえで決まる

* 追加するライフタイムは既存のライフタイムと同じであるべきか
* 既存と同じであるべきでないなら、そのライフタイムはどこで宣言すべきか（impl? fn? トレイトや構造体?）

それで1つの型がリファクタリングできたところで、

* トレイトや構造体にジェネリックライフタイムパラメータを追加した場合、そいつにも同じ作業がいる。最初から繰り返し

ここまでのすべての作業に尋常でない集中力が必要になる
繰り返しの中でライフタイムの宣言箇所の選択が誤っていたことに後で気づいたりすると悲惨だ
「エラーのあるコードをgit commitしない方が良い」という思い込みを捨て、選択を必要とするタイミングでgitに記録するようにして、
作業効率は安定はするようになったが、それでも作業を捨てるというのは気が滅入る
「あ、この関数の引数にライフタイム追加することになるけど、後で戻り値にもライフタイム追加することになるな」なんて思っても一挙に作業してはいけない
少なくとも自分の頭では作業の段取りを崩すだけだった

そしてここまでを全集中して完了してコンパイルを通すところまで持って行けても、クレート外の使用箇所でおかしなことにならないことは保証できない
ボローチェッカーは書かれている使用法が妥当であるかどうかしか検証しないからだ

こっちは体験談として言っているんだから、机上の空論を弄するのはもうやめなさい
486 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 16:58:20.78 ID:KH8yb7Br.net]: Rustはライフタイムさえ正しく書けていれば本当に有用な助けを与えてくれる
しかしライフタイムを正しく書くための助けはほとんど与えてくれないので、自分で書く必要があるときには上と同じような期待をしてはいけない
487 名前：デフォルトの名無しさん [2024/06/29(土) 16:59:51.95 ID:TiydCxUm.net]: 知ったかぶりして間違ったこと書く
やんわり間違いを指摘される
反省せずに開き直る！

またこの流れ
ググればすぐわかるような間違いなのになんなんだろうな
488 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 17:06:14.07 ID:HTwQ17U9.net]: >>474
>>475
それは大きな誤解をしているなあ
ライフタイムアノテーションを間違って書いて矛盾が起きていればコンパイルエラーとなるよ
コンパイルが通れば正しく書けているからプログラマーがそこで困ることはないよ
489 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 17:17:23.37 ID:KH8yb7Br.net]: >>477
いいからこれでも読んでろ
https://github.com/pretzelhammer/rust-blog/blob/master/posts/translations/jp/common-rust-lifetime-misconceptions.md

> Rustのトレイトオブジェクトへのライフタイム省略ルールはどんな状況でも正しいというわけではない
> Rustはプログラムの意味についてプログラマよりも知っているわけではない
> Rustのコンパイラが吐くエラーメッセージでおすすめされる修正はコンパイルが通るようにするが、コンパイルが通り、かつプログラムへの要求をちゃんと満たしたものするわけではない
490 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 17:26:08.00 ID:3fxfEuZj.net]: それは省略ルールの結果が望むものと一致するかどうかは限らないという意味だぜ
間違っていると部分的にはコンパイルが通ったとしてもプログラム全体ではコンパイルエラーとなる
そのミスをコンパイラが見逃すことはない
491 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 18:07:09.50 ID:PsPEDCdZ.net]: 言語を比較しなくても
&Tに比べてRc<T>はリファクタリングしやすいとかいう認識でいいよな

ただ進化論じゃないんだから&Tが淘汰されてRc<T>が生き残るということはない
言語を比較すれば淘汰される言語もありうる
492 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 18:13:00.59 ID:E9RFAyQx.net]: >>469
その逆のリファクタリングを影響範囲が大き過ぎて無理って話をcargoのissueで見たことある
cargoはそれ以外でも技術的負債が溜まってるけど影響範囲が大きくなるから簡単に手を入れられないってことを中の人がよくボヤいてるね
493 名前：デフォルトの名無しさん [2024/06/29(土) 18:24:11.81 ID:bsok8bJg.net]: C/C++をメモリ安全にするプロジェクト
https://www.itmedia.co.jp/enterprise/articles/2406/28/news084.html
Rustイラネになりそう
494 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 18:44:47.93 ID:4ikwzvl0.net]: >>482
それは自動で見つけられる脆弱性の範囲を広げる話
その種の脆弱性をゼロにするRustへと移行する流れはそのまま変わらず
495 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 20:21:20.41 ID:U1RWDnMp.net]: >>480
Rc<T>の比較対象はTやBox<T>
・Tの参照は&T
・Box<T>の参照は&T
・Rc<T>の参照は&T
どれも同じになり&Tは不要とならない

違いはスコープから外れたとき
裸のTはTがスタック上ですぐ消える
Box<T>はTがヒープ上ですぐ消える
Rc<T>はTがヒープ上でカウンタが最後のときだけ消える
496 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 20:23:11.41 ID:KH8yb7Br.net]: >>469
これか……
https://github.com/rust-lang/cargo/issues/7342

> I think the answer here is "Alex thought it was fun to avoid RefCell and Mutex", there's no real technical motivation.

「cloneを避ける/ロックを避ける/参照カウンタのコストを避ける」みたいなゼロコスト主義も節度を持ってやれってことね
とり�
497 名前：�えず「型のジェネリックライフタイム引数を変更するのは多大なコストがかかる」という理解は合っていると思っておくことにするか []: [ここ壊れてます]
498 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 20:23:40.20 ID:KH8yb7Br.net]: >>481だった
499 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 21:57:07.55 ID:PsPEDCdZ.net]: 問題は節度というより抽象化軽視
ゼロコストという損得勘定に強く依存するよりは高コスト抽象化の方がマシ
と判断できなくなる
500 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 22:55:28.22 ID:xDrSJDK+.net]: >>469
それは単にライフタイムに不慣れなだけじゃないかなと思った
構造体に参照を含むのはよくあることでライフタイムパラメタを付けるだけ
あとは関数で参照を含むデータを返す時にどの引数に由来するかを指定することなどしかすべきことはない
慣れてしまうと大したことはしていないよね

そこでもし間違えて指定してしまっても違反があればコンパイラが必ずエラーとするので安心して大丈夫
では何故コンパイラが自動で指定(解釈)してくれないのか？というと、複数の参照に対して別扱いするかどうかや複数の関係指定など各自に方針の余地があるため
501 名前：デフォルトの名無しさん [2024/06/29(土) 23:12:35.54 ID:/LX7F2Md.net]: C/C++だとそのへんを脳内の方針で逸脱しないように人間が監視しないといけない
Rustは楽
502 名前：デフォルトの名無しさん mailto:sage [2024/06/29(土) 23:26:59.72 ID:PsPEDCdZ.net]: 固定長配列をスライスに、BoxをRcに変換すると抽象度は上がる
失敗するかもしれないパターンマッチは抽象度を下げる
コンパイル時または実行時エラーかもしれないborrowも抽象度を下げる
503 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 02:58:29.53 ID:CdZYHoVj.net]: >>467
詭弁

>>469
++

>>474
++おまえもかが口癖になる
504 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 03:44:32.65 ID:K2J9qaLk.net]: >>474
ライフタイム初心者なだけだな
そんなことでは悩まなくなる
505 名前：デフォルトの名無しさん [2024/06/30(日) 05:54:25.07 ID:WATrci3L.net]: >>309
横からすみません。
C＃を関数型っぽく書いたら、ここまではなったのでRustだったらどうなるのか聞いても良いでしょうか？

public static void Main(string[] args) { args.ToList().ForEach(f); }

static void f(string fileName)
{
Console.WriteLine(fileName);
File.ReadAllLines(fileName).Select(g).ToList().ForEach(Console.WriteLine);
}

static Func<string,int,string> g = (line,i) => $"{i + 1,2}:{line}";
506 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 09:33:23.06 ID:L3wyoKVN.net]: どうもならんよ
507 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:12:23.11 ID:BLjMhwlM.net]: リファクタリングのすごさは、外側から見たら何も変化しないことだからね
508 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:30:41.18 ID:8eFU1ITU.net]: >>493
何回ToListすんねんw
ReadAllLines含めて3回とも必要ないやろ
509 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:53:06.05 ID:DQMdIUg4.net]: あえて >>493 で頑張ると
https://paiza.io/projects/sk40IXUgPm0k_VgI1wsHBg

fn main() {
let cwln = |s| { println!("{}", s) };
let g = |(i, line): (usize, &str)| { format!("{:>2}:{}", i + 1, line) };
let f = |file_name: String| {
cwln(file_name.clone());
std::fs::read_to_string(file_name).map(|u8b| {
u8b.lines().enumerate().map(g).for_each(cwln)
}).unwrap()
};

std::env::args().skip(1).for_each(f)
}
510 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 10:54:12.53 ID:BLjMhwlM.net]: do記法のたぐいはラムダで実装しても命令型で実装してもどっちでもいい
外側から見れば同じだからだ
511 名前：デフォルトの名無しさん [2024/06/30(日) 11:17:03.52 ID:msuugTQH.net]: >>496
.net標準にはList型にしかForEachが導入されてないからやな。
C#ではチェインメソッドにしないほうがいいとされてる。
https://learn.microsoft.com/en-us/archive/blogs/ericlippert/foreach-vs-foreach
512 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 12:31:43.09 ID:NR+aRvdr.net]: >>499
「.ForEachしたいけど標準にないからToListする」という考え方が間違い
enumerable.ToList().ForEach()のパターンは最悪

それとそのEric Rippertの意見がMSやC#コミュニティのコンセンサスというわけではないよ
IEnumerable以外ではForEach等の副作用適用メソッドが標準で用意されてるものが多々あるしIEnumerableに拡張メソッド追加して使ってるところもごまんとある
513 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 13:08:54.78 ID:7wkc/L2e.net]: >>497
キツイ
514 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 13:13:35.11 ID:6LaDfHu1.net]: >>500
foreachとForEachくらいは好きなほうでやればいいわな
ものによっては最適化度合いが変わるからそこだけ気にしとけばいい
515 名前：デフォルトの名無しさん [2024/06/30(日) 13:41:54.85 ID:L3wyoKVN.net]: unwarpほんま糞ダサい
516 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 14:01:03.54 ID:BLjMhwlM.net]: 「すべてはオブジェクトである」が糞ダサいのだ
いい感じの構文糖はたいていオブジェクトではない
517 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 15:34:51.28 ID:iQS10/oI.net]: >>497
エラー返しができていない
ファイル一括読み込みでなくバッファリングすべき
本当の関数型だとセミコロンを使うのは邪道
518 名前：デフォルトの名無しさん [2024/06/30(日) 16:34:51.56 ID:WATrci3L.net]: >>497
ありがとうございます。
u8b受け取ってるラムダ式を関数化したらスッキリしそうですね。

>>496
Selectもindexを受け取れるんですが値を返さないとダメで、
あえてvoidなメソッドの後にreturn 0を、入れてエラーが出なくなったと思ったら、
遅延評価なのかfor/foreach/ForEachじゃないと中身を実行してくれないんですよ…orz
（結論、Selectはデータ加工専用で入出力には使えない）
519 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 16:49:10.64 ID:MSv8cbxu.net]: Rustで関数型のように書くなら

use std::env;
use std::fs::File;
use std::io::{self, BufRead, BufReader};

fn main() -> io::Result<()> {
　env::args()
　　.skip(1)
　　.inspect(|file_name| println!("{file_name}"))
　　.map(|file_name| {
　　　File::open(file_name).and_then(|file| {
　　　　BufReader::new(file)
　　　　　.lines()
　　　　　.enumerate()
　　　　　.map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1)))
　　　　　.collect()
　　　})
　　})
　　.collect()
}
520 名前：デフォルトの名無しさん [2024/06/30(日) 16:59:35.48 ID:WATrci3L.net]: 質問です。

.map(|(i, line)| line.map(|line| println!("{}: {line}", i + 1)))
↑
line.mapは文字列へのmapで１文字１文字に番号振ってる様に見えますが、違うのでしょうか？
素直に

.map(|(i, line)| println!("{}: {line}", i + 1))

とは出来ないのでしょうか？
521 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 17:13:06.42 ID:MSv8cbxu.net]: >>508
そこは手続き型で書くと
let line = line?;
のところ
最初のlineはio::Result<String>型
それをmapして次のlineがString型
522 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 17:55:47.01 ID:2aLeyJWV.net]: こうやって関数型を勘違いしたやつが量産されてるんだな
523 名前：デフォルトの名無しさん [2024/06/30(日) 18:10:42.55 ID:WATrci3L.net]: >>509
なるほど、最初のmapと内側のmapで型が違うのですね。
ありがとうございました。
524 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 18:12:41.76 ID:aILYkgH6.net]: さすが二つ名持ちの汚コーダー
ひと味もふた味も違う
525 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 18:28:40.79 ID:MSv8cbxu.net]: 関数型のように書きたいならば基本はfor_eachを使わない
行き詰まりのfor_eachを使うと値もエラーも返せなくなる
526 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 18:46:14.08 ID:DeiuUcf0.net]: >>506
イテレータがどういうものか全然理解してないのな
試行錯誤もいいが最低限の座学知識は必要やぞ
527 名前：デフォルトの名無しさん [2024/06/30(日) 20:38:10.26 ID:oQ6wZd+v.net]: let a: [u32; 4] = [1, 2, 3, 4];
let s: &[u32] = &a[1..3];

a[5]; と書くとコンパイルエラーが発生しますが、
s[5]; と書くとコンパイルは通り実行時にエラーが発生します。

なぜ、 s[5]; が範囲外の領域へのアクセスであることをコンパイル時に見抜けないのでしょうか？

本を見ても、理由が書いてないです。
ただ、そうなるとしか書いてありません。
528 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 21:21:34.70 ID:aS5UFAEb.net]: 見抜けるようになっていないから
a は array である一方で s は slice
array は型として長さの情報を持つ一方 slice は持たない
slice の長さはコンパイル時にわからないしわかろうともしないしチェックもない
529 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 21:23:59.76 ID:MSv8cbxu.net]: >>515
静的にサイズが定数だと静的に比較できるから事前にコンパイルエラーとなる
配列は静的にサイズが定数
スライスもこのように静的にサイズを定数にしてやれば事前にコンパイルエラーとなる
const X: &[u32] = &[1, 2, 3, 4];
let x = X[5];
530 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 21:57:28.27 ID:6Q+TlIxj.net]: 🦀🦀🦀
531 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 22:10:02.00 ID:BLjMhwlM.net]: 本といえども一方通行のメディアではなくなってるんじゃないか
読者の側がそれをどうしても知りたい気持ちを表明しなければならないのが双方向でしょ
532 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 22:48:34.24 ID:NrRL076G.net]: >>513
一体全体何を言ってるんだ？
533 名前：デフォルトの名無しさん mailto:sage [2024/06/30(日) 23:09:55.43 ID:MSv8cbxu.net]: >>520
for_eachは値を返せない
関数は基本的に値やエラーを返す
イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる

>>507のように表示するだけで値を返さない場合であっても
関数はエラーを返さなければならない
534 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 00:45:59.76 ID:d9FHgeU6.net]: >>521
>for_eachは値を返せない
for_eachはunitを返してるよ

>関数は基本的に値やエラーを返す
voidやunitやnilを返すものも関数だよ

>イテレータ利用で値やエラーを返すためにはfor_eachではなくcollectやfoldなどを用いる
try_for_each使ってね
file openやprintのような副作用をイテレータのmapで行うのは関数型の考え方からは程遠いよ
535 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 01:02:37.18 ID:3Woy0c9R.net]: 値を()しか返せないのでは意味がない
536 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 01:19:54.94 ID:CgZJmBCn.net]: お前の人生よりは意味あるよ
537 名前：デフォルトの名無しさん [2024/07/01(月) 04:16:03.32 ID:VTE9nWpJ.net]: unwrapをmapで代用とかセンス無さ過ぎ
538 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 05:26:16.34 ID:WAZyoaEd.net]: 見抜いたことを全て警告するコンパイラがあったらこんな感じになるのか
539 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 05:49:45.95 ID:ppYg1fh2.net]: Rustは清書用(キリっ
540 名前：デフォルトの名無しさん [2024/07/01(月) 05:51:10.72 ID:D/wxxrcg.net]: 犯人不明ボイス・トォ・スカル被害者にしている者皆判明
AIで被害者が苦しんでいる映像を作成してそれで喜んでいる脳細胞を読み取れば使用しているかの判定
AIで自分が高みの見物ができるかどうかも判定
あとは下記を参考にして行えばよい

いじめで殺害したかも判明するので迷宮入り事件犯人を絞り込める
隠しカメラの場所も判明

忘れた記憶を再び思い出せるようにする脳細胞を発見！
2024.06.28
「あなたの一番古い記憶は？」人は覚えていても2歳以前の記憶にアクセスできなくなっている
2023.11.30
なぜ私たちは起こってもいない間違った記憶をしてしまうのか？
2023.11.27
自分でも気づいていない「記憶の間違い」を脳波で判断できると判明
2023.10.19
富山大、睡眠中の脳で行われている推論の演算を神経細胞レベルで解明
2024/06/26
サイコパスはためらわない？－－嘘つきの脳のメカニズム
2019/09/26

脳を刺激して特定の記憶を呼び戻す技術「記憶プロテーゼ」を開発
2024/02/21

「0」を”思う”ときの脳活動は「1」に近い！捕食者への恐怖がゼロの根幹だった？
2024.03.07
>>MEGを使うと、脳内でわずかに発生する磁場変化をとらえて、脳活動を記録することが可能です。
>>（※脳波計が脳の電気活動を読み取るのに対して、脳磁計は脳の磁気活動を読み取ります）

東工大、磁束集中器を用いない高感度「ダイヤモンド量子センサ」を開発
2024/06/07
>>日常的な検診や脳機能のより詳しい研究や、ブレイン・マシン・インタフェースの研究などへ大きく貢献できると期待されている。
541 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 06:29:11.19 ID:XAeGvvJG.net]: >>525
unwrapは使わずにmapでNone/Errを透過的に渡すのはRustの基本
542 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 07:19:14.88 ID:WAZyoaEd.net]: これmapメソッドでもmap関数でもない中立な勢力が勝つパターンだ
543 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 11:47:54.40 ID:LZ9kVfeK.net]: Functorのmapなんだよね
でもFunctorは定義されてなくて統一的に扱えないんだから
Result/Optionはfmapとか違う名前にしておいたほうがよかったと思う

どっちにしろmap/fmapで副作用はアンチパターン
544 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 11:55:40.56 ID:14Z1Ksgh.net]: fmapなんかflatMapと勘違いされるだろ
545 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 12:47:47.85 ID:Z0Kzqg/U.net]: そんな勘違いをする人にRustは無理
546 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 12:59:53.25 ID:irzLgX5l.net]: >>525
こう書くとresultがErrの時に返せずここでpanicになってしまう

　let val = result.unwrap();
　f(val)

そのためpanicしてもいいとか絶対にErrとならない特殊な場合を除けば
unwrapを用いてはダメでmapを使ってこのように書くんだよ

　result.map(|val| f(val))

ここで本当に関数fを呼ぶだけならresult.map(f)と簡略化できるけど
f(val)の部分は式やブロックの可能性もあるので簡略化せずに進めるね

これは以下と同等でErr(err)の時に保持してくれている

　match result {
　　Ok(val) => Ok(f(val)),
　　Err(err) => Err(err),
　}

ちなみにf(val)もResultを返すときは
mapの代わりにand_thenがある

　result.and_then(|val| f(val))

つまり以下の二つは同等

　result.map(|val| f(val))
　result.and_then(|val| Ok(f(val)))

この場合はもちろん簡素なmapを用いるべき
547 名前：デフォルトの名無しさん [2024/07/01(月) 13:41:34.54 ID:JlB5uk0q.net]: Rustを10年以上使ってるひとに質問です
Rust本体をバージョンアップしたときに
動かなくなった旧バージョン用のcratesや自分のプロジェクト(main.rsなど)は
どれくらいありましたか？
またdeprecatedやobsoletedにされた機能は
使えなくなるまでに実際何年くらい使い続けられましたか？
548 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:05:59.07 ID:/HpLpXor.net]: Rust 1.0からまだ10年経っていない
Rustは3年毎のedition制度があって後方互換性がない変化はeditionが変わるため安心
今も最初のRust 2015 editionがサポートされてる
さらにedition移行支援ツールもある
Rustは他言語と比べてかなり恵まれてる良い環境
549 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:11:38.44 ID:JlB5uk0q.net]: >>534
>ちなみにf(val)もResultを返すときは
の条件なら
>つまり以下の二つは同等
>　result.map(|val| f(val)) // Resultを還さないf
>　result.and_then(|val| f(val)) // Resultを還すf
じゃないんですかね(Ok(f(val))は蛇足)
550 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:22:14.04 ID:seu0xN2c.net]: Resultを返すか返さないか関係なくこれは常に成り立つね

>>534
＞以下の二つは同等
＞ result.map(|val| f(val))
＞ result.and_then(|val| Ok(f(val)))

例えばf(val)がOptionを返したとしても成立するよ
551 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:22:38.11 ID:14Z1Ksgh.net]: flat_map の関数名を and_then にしたのはどこの言語の文化？
552 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:43:32.98 ID:WAZyoaEd.net]: iostreamの記号をまるでセガサターンのように見下して英単語を推した文化
553 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:48:54.46 ID:JlB5uk0q.net]: and_thenはor_elseに対してのantitheseだと思った
554 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:51:31.68 ID:seu0xN2c.net]: result1.and(result2) がまずあって
result1.and_then(|ok1| return_result2(ok1)) が関数版だね
OptionでもResultでも同じ命名
555 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 14:59:21.90 ID:3i64JhgU.net]: iostreamの << をRustに導入しなかったのはなぜ？
556 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:05:11.12 ID:kC5U6Id4.net]: std::fmtで十分だから
557 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:05:34.52 ID:YDWAPNrm.net]: うるせぇやりたきゃShl実装しろ
558 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:30:41.32 ID:wNG1bhSA.net]: >>543
単純な二項演算子でやると書式指定の範囲を制御できないんだよ。
C++ ではストリームに対する書式指定は永続的な効果を持っていて、その効果を上書きするまで続く。
普通の方法で指定したらグローバルな影響を持ってしまうのは明らかにまずい。

iostream が出来たときは可変長引数の関数を型安全に扱う方法 (variadic template) が無かったし、
書式指定文字列をコンパイル時に解釈して安全に扱う方法 (constexpr) も無かったから
その範囲内で当時の知見で比較的マシな形にしたらああなったという程度のもんで、
今の考え方からすると iostream は真似したいようなもんじゃない。

むしろ C++ のほうが新しい仕様では Rust 風のやり方に寄せて来てる。
559 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:53:07.19 ID:2HyCglUW.net]: >>543
ダサすぎるから
560 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 15:56:35.04 ID:iVgAAf6K.net]: rustもprint時のstring interpolationはもう少しどうにかならんものかね
561 名前：デフォルトの名無しさん [2024/07/01(月) 18:51:52.61 ID:r9fpSp0F.net]: macroなんで自分で描き替えればええんやで
562 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 20:45:22.07 ID:WAZyoaEd.net]: 自作した後の自己肯定を10年続けるまでがプログラム技術
563 名前：デフォルトの名無しさん mailto:sage [2024/07/01(月) 23:04:21.05 ID:3i64JhgU.net]: 昔、C++でprintf使ったら怖い人に怒られたのに
今じゃあれはクソ設計だったって評価に固まってるんだね、英語圏でも
564 名前：デフォルトの名無しさん [2024/07/01(月) 23:12:10.92 ID:wNG1bhSA.net]: >>551
C/C++ の printf は iostream 以上にカス。
型のチェックがガバガバだし、ちゃんと理解してないやつのほうが多いので常に問題を引き起こしていた。
ただ、記法としてはこれで良かった。
565 名前：デフォルトの名無しさん [2024/07/02(火) 02:06:02.53 ID:bkJ9zxrb.net]: 今の C/C++ の printf はコンパイル時に型チェックして警告してくれる
566 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 05:00:17.05 ID:VNjymWLQ.net]: >>553
型チェックできて型がわかっているのに
なぜ%dや%fや%sなど指定しなきゃいけないのか理解できない
型がゆるゆるだった大昔の遺物にみえる
567 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 06:06:14.65 ID:wHmBy3hI.net]: >>554
みえる、じゃなくて完全に遺物だろ
568 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 06:44:02.90 ID:VNjymWLQ.net]: 表示はRustのDisplayトレイト実装方式が洗練されていて使いやすくていいね
569 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 08:28:24.43 ID:UD4Nu927.net]: 仕様書が聖書のようなものだから遺物だろうが仕様書に逆らうわけにはいかないじゃん
570 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 08:41:47.20 ID:hGRi0mb2.net]: >>544
C の関数は基本的にはちゃんと型はついてるが可変長引数は静的な型情報を捨てること実現してる。
もちろんそれを引き継いだ C++ も。
C++ は後に variadic template による安全な可変長引数を導入したが古いスタイルの可変長引数も廃止はしてない。
言語仕様を素朴に実装したら型はわからないんだよ。
printf などの一部の関数に限っては「関数の型情報によらずに」コンパイラが特別扱いでチェックしてる。
関数の型を元に検査してるんじゃなくて printf の仕様をビルトインして特別扱いしてるの。
571 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 10:27:11.96 ID:LnXo4/R2.net]: >>538
result.and_then(|val| Ok(f(val)?))
とか
result.and_then(|val| Ok(f(val).unwrap()))
じゃなくて
result.and_then(|val| Ok(f(val)))
で良いのはなぜ？
572 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 10:37:23.15 ID:tsLlTVbC.net]: Rust初めて使ったときは「println! みたいな基本的なものがマクロで？大丈夫かこの言語」みたいに思ったもんだが、
よくよく考えるとマクロにせずに、柔軟なシグニチャでなんとかしようとする他の言語のほうがよっぽど醜いもんな。
573 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 10:55:15.33 ID:/ZI4FWA6.net]: >>559
上2つはResult<T>
最後のはResult<Result<T>>かResult<Option<T>>
ネストが一つ深くなる
574 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 11:50:20.39 ID:hGRi0mb2.net]: >>560
C++ のライトユーザは関数テンプレートのことを誤ってテンプレート関数と呼ぶことが頻繁にある。
関数テンプレートが関数であるという誤解が言葉になって表れてるんだと思う。
単に使うだけなら関数みたいに見えてしまうからかもしれない。

関数テンプレートは関数を生成する元になるテンプレートだから関数テンプレートなので「生成する」というところに着目したらマクロで生成するのでも理屈はあまり変わらないかもしれない。

ただ、 LISP 系言語の経験から言うと構文レベルで制御されるマクロはエディタのサポートが受けづらいし、ドキュメントを型で表現できないのはやりづらい。
マクロ展開の失敗がどういう失敗なのかをきちんとエラーメッセージにするのも難しい。
デメリットもあるけど、どうせどこかに問題があるならこのくらいで良いという潔さは感じる。
575 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 12:37:13.61 ID:UD4Nu927.net]: 仕様書がなくなっても
統合環境の支援の成功体験から逆算された縛りがあるんだな
576 名前：デフォルトの名無しさん [2024/07/02(火) 16:01:50.82 ID:LnXo4/R2.net]: and_thenってネストが深くても自動で中いじってくれるのか
577 名前：デフォルトの名無しさん [2024/07/02(火) 17:51:34.66 ID:XMmeU2jA.net]: Slint ってなんなん？ javascript ?
conrod とどう違うん？
578 名前：デフォルトの名無しさん [2024/07/02(火) 18:31:45.59 ID:W5A1QJhP.net]: conrodならもう死んだよ
579 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 18:32:06.29 ID:0AnHLV8o.net]: >>559
Rustでそれらは全てmatchになるので置き換えて比較すれば理解は簡単
ちなみにmatchにすると記述が長くなるが同レベルで「?」オペレータ適用できるメリットがある

result.and_then(|val| f(val))
これはこう置き換えられる
match result {
　Ok(val) => f(val),
　Err(err) => Err(err),
}

result.map(|val| f(val))
これはこう置き換えられる
match result {
　Ok(val) => Ok(f(val)),
　Err(err) => Err(err),
}

つまり常にこれが成り立つ

>>534
＞以下の二つは同等
＞ result.map(|val| f(val))
＞ result.and_then(|val| Ok(f(val)))
580 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 18:34:46.10 ID:0AnHLV8o.net]: >>565
SlintはGUI部分だけ専用スクリプトで宣言して
プログラムはRustでもC++でもJavaScriptでも記述できる
581 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 22:09:25.08 ID:PHqzDXJL.net]: RustのGUIまわりは安定しない印象
conrodやdruidやorbtkのようにここ数年内に消えたものもあるし、いま人気のものも今後消えないとは言い切れない感じがする
582 名前：デフォルトの名無しさん mailto:sage [2024/07/02(火) 23:44:50.93 ID:sYgKhdog.net]: RustでGUIならこの5つ
https://iced.rs/
https://slint.dev/
https://tauri.app/
https://www.egui.rs/
https://dioxuslabs.com/
方向性がそれぞれ異なるので目的に合わせて選ぶ
583 名前：デフォルトの名無しさん [2024/07/03(水) 03:55:17.90 ID:aYT0CHki.net]: tauri遅いな
eguiはサクサク
584 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 06:25:46.46 ID:uJMJjlOC.net]: >>570
tauriはその中に入れるべきじゃないだろ
あれはReact/JSだぞ
585 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 07:06:30.59 ID:OX+N1U2y.net]: >>572
無知すぎ
Reactは全く関係ない
併用可能な一つに過ぎない

TauriではJavaScriptを一切書かなくても利用可能
Rustによるプログラミングのみでも使うことができる
586 名前：デフォルトの名無しさん [2024/07/03(水) 09:04:55.71 ID:TWMTGehv.net]: rstkはどうなの？
587 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 20:03:02.84 ID:zo80GwO2.net]: しかしほんとにデスクトップアプリのライブラリってすぐ出ては消えていくな
自分で作ったほうが安定するんじゃないか
588 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 22:16:18.13 ID:opT6Sw/L.net]: クロスプラットフォームでいくならwinitとwgpuぐらいは頼らないと無理じゃないかな。
しかしその2つもまだまだブレイキングチェンジ激しい発展途上だけどね。
589 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 22:53:26.72 ID:cnEeYmV/.net]: >>574
*/Tkは30年以上の歴史と実績があるGUIライブラリ
rstkはそのRust版
590 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 23:54:41.68 ID:nLMSU1jW.net]: >>573
Yewのこと？ならそう書けよYewなんてくっそマイナーでReact使うのが普通なのに
591 名前：デフォルトの名無しさん mailto:sage [2024/07/03(水) 23:56:15.32 ID:nLMSU1jW.net]: Yew使ったことあるけどゴミだぞまじで
592 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 00:31:14.93 ID:gMzXB5nS.net]: 30年くらい前にTcl/Tkを使ったわ。
593 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 00:37:01.85 ID:0fbU9cKr.net]: >>575
利用者が集まらなきゃ結局のところ本番環境で使われないもんね
MAUIもだけど本番環境で使われなきゃ不具合修正すらされずにフェードアウトしていく
594 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 04:07:16.49 ID:H+976rVP.net]: >>570
eguiの公式サイト、オサレね
595 名前：デフォルトの名無しさん mailto:sage [2024/07/04(木) 07:04:39.24 ID:pjeQ5Ua2.net]: サイト自体が見本なのな
596 名前：デフォルトの名無しさん [2024/07/04(木) 10:17:42.23 ID:HAZY/W56.net]: reactもこの10年でだいぶ変わったわな。
プレゼンテーション層はそういうもんかもなと思ってる。
597 名前：デフォルトの名無しさん [2024/07/05(金) 08:36:28.68 ID:GQkuHNKI.net]: 銀河英雄伝説で考えるセキュリティ--将来の「帝国の双璧」が陥った罠とセキュリティ業界
https://japan.zdnet.com/article/35220819/
598 名前：デフォルトの名無しさん mailto:sage [2024/07/05(金) 10:29:56.20 ID:G0wJmtVU.net]: >>574 >>577
rstk より tk ( https://crates.io/crates/tk ) の方が良いよ
599 名前：デフォルトの名無しさん mailto:sage [2024/07/05(金) 18:22:04.62 ID:cNWaNn+n.net]: どちらも利用者少なくて数の差ではわからんな
600 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 04:04:15.80 ID:MPM8/XaB.net]: Tkは何十年も前のGUIで古いからね
601 名前：デフォルトの名無しさん [2024/07/06(土) 04:24:49.23 ID:mF2Bv0pD.net]: やりたいことを出来る範囲で最小限の道具を選ぶのが望ましい。
Tk で足りるときは Tk を使えばよい。
602 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 09:36:32.81 ID:5g1fLWJR.net]: UNIX系でGUIをどうしても使わないといけない場合にTk使ってたけど
今はhtmlでいいかなって
603 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 09:36:55.52 ID:tDR9EaCv.net]: wgpu最強だが変化速過ぎ
604 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 10:12:50.18 ID:fehAbjyn.net]: 正直GUIをRustで書くメリットが思いつかない
ただの2DグラフィックでRustの実行速度を求めるってのはおかしな話だと思うもん
ロジックをRustで書いてGUIは安定してるReactでいいよ
605 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 10:14:23.55 ID:5g1fLWJR.net]: wgpuは三角を書きたい人向けでGUIとは関係ない
606 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 11:05:29.63 ID:l5YBQ3zH.net]: >>592
お前がそう思うならそうなんだろう
お前ん中ではな
607 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 12:27:12.12 ID:KR8eM4HE.net]: >>592
reactはデータリフトアップして上にまとめるのめんどい。状態管理だけにライブラリ導入とか無理あるんじゃねーの
608 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 12:35:51.52 ID:5g1fLWJR.net]: streamlitなどのHTML書かないでも作れるようなのがメジャーになればいいんだけど
609 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 12:47:45.00 ID:5g1fLWJR.net]: reactがパックされてて高度なページはjinjaみたいので中のデータだけいじれればなんでもいい気がする

通常のページの記述はhtmlではなく素のrustで簡単に書ける必要がある
610 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 13:00:47.32 ID:mF2Bv0pD.net]: ウェブ技術系は普段使いするにはリッチすぎるんだよな。
屋上屋を重ねまくった一番上でしょうもないことをするのは気が引ける。
611 名前：デフォルトの名無しさん mailto:sage [2024/07/06(土) 13:56:26.87 ID:5g1fLWJR.net]: streamlitレベルでいいんだけどな
612 名前：デフォルトの名無しさん [2024/07/06(土) 14:33:03.19 ID:+47S9kNa.net]: rust版のstreamlit作れよ
613 名前：デフォルトの名無しさん [2024/07/06(土) 14:56:55.97 ID:X3tW4qHs.net]: タウリンなんていらん
eguiで充分
614 名前：デフォルトの名無しさん [2024/07/06(土) 22:06:51.02 ID:PIuhFLFS.net]: Rustってオブジェクト指向言語ではないということですが、それでも困ることはないんです
615 名前：か？ これが最後の言語だ！とRustって名付けたんですか？ []: [ここ壊れてます]
616 名前：デフォルトの名無しさん [2024/07/06(土) 22:35:00.58 ID:KApGuCzH.net]: Rust触ってないから分らんけど、QtのRustラッパーライブラリは無いのん？
一応Android/iOS含めたソースコードレベルでのマルチプラットフォームライブラリに進化しているらしいが、Haskellにすらラッパーライブラリあるんなら、Rustにも探せばあるんじゃ？
617 名前：デフォルトの名無しさん [2024/07/07(日) 00:52:56.61 ID:goRFIXq7.net]: >>602
ネタにマジレスかもしれないけどRustはオブジェクト指向的なものも使えるよ
構造体にメソッドを持たせたり、インターフェースのようなものも扱える
継承はないけど、これはむしろ「その方が良い」というもので、同じくモダンな言語であるGOでも継承は無くしてる
618 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 01:50:01.52 ID:NnH56+1c.net]: オブジェクト指向プログラミングには
クラス継承という悪いやり方を用いるダメな方法と
クラス継承を用いない正しい方法があって
RustやGoなどのモダンな言語は後者の方法をサポートしている
619 名前：デフォルトの名無しさん [2024/07/07(日) 08:48:31.04 ID:5sr/rOi5.net]: >>603
ないわけじゃないけどまともに使えるレベルではないらしい。使ってないから知らんけど。
Qt自体QMLとか迷走してる感じあるし結局JSでやるならもうReact使えばいいんじゃね？感ある
620 名前：デフォルトの名無しさん [2024/07/07(日) 09:17:14.13 ID:7aG8TPof.net]: >>604-605
ありがとうございました。
「継承」って良いからオブジェクト指向言語の機能になっていたのではないんですか？
なんか時代とともに、昔は良いとされていたものが今ではダメになったりするんですか？
なぜそんなに揺らぐのでしょうか？
言語の設計の学者はぼんくらばかりなんですか？
621 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 09:17:45.74 ID:LJE8DJUz.net]: 継承がないほうが「正しい」というのは行きすぎた思想だよ。
正しく使えないカスばっかりだという現実に敗北しただけ。
622 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 09:49:42.70 ID:Qx35uTG5.net]: 何がダメかというと「ある型(クラス)が別の型(クラス)の実装を継承してしまうこと」でこれが依存関係となり負の連鎖をもたらす
クラスの継承はこれに該当するから使ってはいけない
Rustにも継承とみなせる機能はあるけれど上記に該当しないため大丈夫
そこが決定的な違い
623 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:06:45.11 ID:rz+I+TB4.net]: >実装を継承してしまうこと」でこれが依存関係となり負の連鎖をもたらす
実装継承を使えないレベルの人はだいたいこういうふわっとした認識だよね
624 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:11:15.42 ID:Eha1J0DV.net]: 暗殺術を正しく使える賢者がいる国なんてあったら嫌だなあ
正しく使える者など絶対存在しないという思想は行き過ぎではなくむしろ穏健派
625 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:27:32.62 ID:nRN7u0+P.net]: 全部が悪いと言う話じゃないけど

既存部分をただ継承させるだけならいいけど一部を上書きしたりして
それが全ての箇所で矛盾のない正しい挙動になるか判定が難しいか不可能な場合がある

結果実装コスト以上に考えざるを得ない…残念なことに本当に楽をしたのかどうか不明な場合がある
継承がないとそれは避けられるから使うな！と言う人が出てくる
626 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:29:57.11 ID:nRN7u0+P.net]: 変数などに細かいアクセス制限のない言語は特に陥りやすい
制限があったところで制作者がそれを適切に選ばなければならない

どうしても経験や思考時間を必要とする
ガチ勢にはそれが無駄に思えるんだろう
627 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:32:06.74 ID:syATK/7U.net]: 実装継承は問題を引き起こすだけでなく
代わりの継承機能を提供することで
実装継承は全く不要になったことが大きい
そのためRust、Zig、Nim、Goなどモダンな言語はいずれも言語仕様からクラスを追放している
628 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:33:57.16 ID:nRN7u0+P.net]: それをやっても実質オーバーライド問題は解決されていないけどな
629 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:45:17.84 ID:4XBGKwNL.net]: >>607
実装継承はすごく便利だからオブジェクト指向言語では誰でも使いやすい機能としてサポートされてた
でも便利すぎて乱用されたからその経験と反省から不便でも乱用されにくいようにした方が得策という考えに至った言語開発者が増えたというのが2010年代
だから今は実装継承は上級者向けの機能という扱い
GoでもRustでも一般的なオブジェクト指向言語よりもわざと使いにくくすることで利便性と問題点を理解して実装方法を選択できる上級者向けの技術になっている
630 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:46:54.77 ID:RLTFRTn6.net]: >>615
それは(実装継承となる)クラスでのみ問題となるよな
631 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 10:53:40.16 ID:suA6qkkI.net]: >>616
デタラメを書くなよ
問題となる機能の代わりに便利で問題を起こさない機能を導入したのがRustだ
頭の固いクラス原理主義の人だけが使いにくいと主張してるが
クラスの洗脳から解き放たれた普通の人たちはRustが便利で使いやすいとの理解に至っている
632 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:05:57.49 ID:nRN7u0+P.net]: >>618
それは違うかなｗ
Rustで具体的に他と何が違ってて便利になってるか明言できるか？

Rustでも本質は変わってないのでなんも考えないでコピペ（継承）は避けましょうね
ぐらいのレベルでしかない
633 名前：デフォルトの名無しさん [2024/07/07(日) 11:21:22.62 ID:goRFIXq7.net]: >>607
当時は良いと考えられてたものが後から振り返って「あれは良くなかった」と分かる例はプログラミングに限らず多くあるだろ
Cの時代にRustを設計しろというのは無理で、その間にC++やJavaを経験し、そこで生まれた課題意識がないとGoやRustは生まれなかった
ニュートンの時代に古典力学を超えた量子力学を発見しろみたいなもの
634 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:23:38.24 ID:E46Yge5y.net]: >>619
コピペを避けるためにあるのが継承
ただし継承には2種類あって
>>609に説明がある実装継承とそうならない継承がある
実装継承の典型例がクラス継承
実装継承は他の型(またはクラス)に実装を完全に依存してしまっているために硬直化や崩壊などを招いてしまう
解決方法は単純で実装継承とならない継承機能をRustのようにサポートすればよい
635 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:31:52.81 ID:Eha1J0DV.net]: 当初から、算数の四則演算の型を継承で説明できないことを
知りながら無理を通したぼんくらが流行らせたのだ

難しい算数よりも布教しやすい教義を優先するほうが儲かるという判断
その判断が合理的と思うかどうかは人それぞれ
636 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:55:49.26 ID:nRN7u0+P.net]: 根本的に継承だけの問題じゃない
結局可視であろうがなかろうが関数自体の挙動が理解しないといけない

addがあってもリストの一番前に追加するか後ろに追加するかと言う機能の違いが合って
コーディングする側がそれを統一的に扱って思った場所に追加されずにバグになる
そういう話だからトレイトだからとか継承亡くしたからとかどうとか関係ない
637 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 11:59:33.31 ID:kX4AKaVh.net]: 継承はなくても良いがあると便利 vs 継承はあってはならない
C++は知らなくてもいいが先に知っておくと理解が速い vs C++の理解はいらない

こういう境界線のビミョーな議論だと「まだ結論は出てない」と嘯きやすく続けやすいんだろうか
638 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 13:43:23.71 ID:7CPxEWjC.net]: interfaceはおっけー、abstractは隠蔽されるからだめってことだよ
継承全てが悪というわけではない
639 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 13:46:30.77 ID:7CPxEWjC.net]: kotlinでもabstractクラスはコード自動生成するときしか書かないもん
rustはtraitで十分だし
640 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 14:05:34.19 ID:nRN7u0+P.net]: rustにも派生はあるじゃん
641 名前：デフォルトの名無しさん [2024/07/07(日) 16:52:52.64 ID:7aG8TPof.net]: 大きなプログラムを実際に書かずに、本を読むだけで、この言語のこの仕様は悪いとか良いとか判断できるようになりますか？
642 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 17:13:03.91 ID:KUDE2scl.net]: 継承はいらん。

理想(のひとつ)はダックタイプで、継承は実装上の都合でそうなっている妥協の産物でしかない。
643 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 17:36:36.74 ID:h+XkpNj2.net]: 今まで築いてきた価値観を繰り返し短い言葉で否定して徹底的に壊すというのが洗脳の基本

「継承は悪」「モダンな言語に継承はない」「Rustでは継承による問題は発生しない」(※全部嘘ですよ)

最初に洗脳をはじめた人と違って
洗脳者に洗脳された人は本質を理解していない
そればかりか真実かどうかなんてもはやどうでもよく
自分が信じてることだけが真実だと思っている
だから議論しようという気もなく一方的に同じことを繰り返し書くだけ
掲示板界隈では身近によくあることなので気をつけようね
644 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 18:10:28.88 ID:rdCPsToy.net]: 継承はプログラミングで絶対に必要な重要な機能で重複コードを避けることができる
ただし継承といっても複数の方法があって実装継承だけは害を招いてしまう

実装継承とは別の型の具体的な実装をそのまま継承してしまうことを指す
つまり実装継承をすると二つの型の間に不必要に強力な依存関係が生じてしまう

クラス継承でプログラムを書くと自然にこの害悪な実装継承となってしまう
そのため様々な異なる方針のモダンな言語が同じ結論に達してクラスを言語仕様から無くした

Rustではトレイトを使うことで健全な継承機能のみを使うことができる
特にトレイトのデフォルト実装はどの型にも依存しないため実装継承にならずに健全な継承のメリットを最大限に享受することができる
645 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 18:53:59.08 ID:0Udg54Yk.net]: >>628
たくさん本を読み自分の頭で考える努力をすればある程度まではなれる
ただし実地の経験がなければ最終的には他人の受け売りを判断基準にするしかなく
経験のある人間に比べると妥当な判断ができない状況が多くなる

言語の仕様は一面的に良いとか悪いとかという判断を下せるものはほとんどない
長所短所を把握した上でどういう状況であれば他の仕様に比べて優れていて
逆にどういう状況であれば他の仕様に比べて劣るのかという
状況に合わせた判断が必要

つまり妥当な判断を下せる確率を上げるためには
言語の仕様を把握する力よりもそれが使われる状況を幅広く奥深く想定する力を身につけることが重要
これを本を読むだけで身につけようとしてもすぐに頭打ちになる
646 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 19:04:36.65 ID:tn8SIXEe.net]: >>622
>算数の四則演算の型を継承で説明できない
詳しく。
647 名前：デフォルトの名無しさん [2024/07/07(日) 19:34:52.42 ID:goRFIXq7.net]: >>628
他の言語での開発経験がある人が仕様を見て「この言語のこの仕様は好き/嫌い」と言うことはあると思う
どの言語も初心者という人だと無理
それに言語の良し悪しなんて点数で評価できるようなものでないし、好みの問題だったり、ライブラリなどの周辺環境だったり、作りたいもの次第だったりする
648 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 21:58:17.95 ID:rdCPsToy.net]: 好き嫌いと良い悪いはしっかり区別つけなければならない
他の型との間で不必要に強力な依存関係が生じてしまう実装継承は悪い
この実装継承となってしまうクラス継承は悪い
Rustに実装継承はなくトレイトを用いることで健全な継承を活用してプログラミングできる
649 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 22:26:34.08 ID:rVoIwJvq.net]: 受け売り知識しか持たないとこういう感じで論拠薄弱で空疎な意見しか書けなくなる
いい反面教師だね
650 名前：デフォルトの名無しさん [2024/07/07(日) 22:51:49.25 ID:goRFIXq7.net]: Rustが継承の問題を防げるのってトレイトだけじゃなくてenumの存在も大きいよね
静的ポリモーフィズムを自然に実装できるから、多態のために無理やりインタフェースに当て嵌めようとしたり、ダウンキャストが必要になったりといったものを防げる
本質的に違うものを抽象化しようとして失敗してる例を見たことのある人はそれなりにいるはず
651 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 23:03:31.83 ID:Eha1J0DV.net]: >>633
整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない

それと文字列 + 文字列が定義されている言語では
分数 + 整数の定義に必要な関数も継承したくない
その関数は文字列と無関係だから
652 名前：デフォルトの名無しさん [2024/07/07(日) 23:46:19.40 ID:QlaAOMK5.net]: >>638
>整数クラスは分数クラスを継承したいが、分母を表す変数は継承したくない
普通、C++だと、整数クラスを作っておき、
分数クラスはそれを継承せずに、
整数クラスを2つメンバに持つクラス
として定義しますよね。
その場合、整数クラスと分数クラスは継承関係を持ってない。
653 名前：デフォルトの名無しさん mailto:sage [2024/07/07(日) 23:51:53.41 ID:gwkq/Sum.net]: >>635
クラス継承の問題はある程度の規模でプログラミングしてきた人の多くが体験してきて、
その根本的原因は実装継承にあることが多くのサイトで解説されている通りだけど、
従来の言語ではクラス継承に代わる手段が弱かったり不便であるため、
仕方なく欠陥のあるクラス継承を使い続けてきた不幸�
654 名前：ﾈ歴史があるんだよ。 クラス継承を使わずにすむRustは恵まれてる。 []: [ここ壊れてます]
655 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 00:13:34.95 ID:dSFAEVvP.net]: >>638
分数クラスを継承して整数クラスを作りたいという要求と
分母を表す変数は継承したくないという要求が矛盾してる

分数クラスを継承して整数クラスを作りたいということは
分数を特化したものが整数であるというモデルを
分数クラスと整数クラスの実装でも作りたいということ
そのためには整数クラスにも分母を表す変数が当然必要

矛盾した要求が実現できないのは実装技術の問題ではなく要求の不備
656 名前：デフォルトの名無しさん [2024/07/08(月) 00:24:32.58 ID:aZihrzFg.net]: >>607
コードメトリック - 継承の深さ (DIT)
https://learn.microsoft.com/ja-jp/visualstudio/code-quality/code-metrics-depth-of-inheritance?view=vs-2022

継承もやりすぎると毒になるってだけで、全くダメってわけじゃない。
657 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 00:26:00.53 ID:wE6spjgC.net]: >>638
不適切な継承の典型例だな
658 名前：デフォルトの名無しさん [2024/07/08(月) 00:36:15.98 ID:aZihrzFg.net]: >>638
数学では整数の組から分数作るけど、整数クラスが親クラスじゃないのは変じゃない？
（そもそも、継承より整数クラスのインスタンスを分子用と分母用の2個使う委譲スタイルの方が適切だと思うけど）

(n,m)とn/mは同型
659 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 01:24:33.08 ID:QXtalhpf.net]: どういう用途のためにクラスを作ろうとしているのか不明瞭な段階で
特定の実装方法が適切だと思い込むのは感心しない
660 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 05:17:42.23 ID:9vKk3LiW.net]: >>630
継承自体は悪くない
重複コードを回避できて保守性も向上する
つまり継承自体は良いもの

ただし実装継承だけは悪
異なる型同士に過度な依存をもたらし保守性を悪くする
クラス継承は実装継承となるため悪
モダンな各言語がクラスを排除した理由はそのため

Rustに実装継承はなく継承でそのような問題を起こさない
661 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 09:13:52.72 ID:1Z2Y8mSg.net]: 継承で重複コードを回避できるのは実装も共有する継承だけ
つまり実装継承だけ

Rustスレでこんな初歩的なことを説明しなきゃいけないのはすごく悲しい
662 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 09:32:49.17 ID:QAb8fFud.net]: 今回はいつまでやるの？
663 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 09:42:44.60 ID:jJBNmhlI.net]: >>647
実装継承の意味を理解したほうがいいんじゃね？
ある型Aの実装を別の型Bが継承することが実装継承と呼ばれているんだよ
これは不必要に依存関係が強すぎて片方を機能拡張しようとしたときなど破綻を招きがち
だから実装継承となるのは避けるべきと言われているね
664 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:06:04.28 ID:eiH/KN8v.net]: ワイの思う継承はenum_dispatch crate でやれるから困ったことないなぁ
お前らの心の中の継承は知らんがw
665 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:42:22.99 ID:UCsocQnW.net]: 分数はバカっぽい
有理数と言え
666 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:42:53.94 ID:29FzOd3r.net]: >>647
Rustに実装継承はないけど
継承があり重複コードを回避できている
667 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:43:30.84 ID:29FzOd3r.net]: 例えばどんな型でどんな内部構造でも
その型にトレイトのnext関数を実装するだけでイテーレータとして機能するが
その時に他のメソッド(nthとかmapとかfoldなど)のコードを自分で書かなくても自動的に継承されて機能する
668 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:44:27.48 ID:29FzOd3r.net]: これをデフォルト実装と言い特定の型の構造に全く依存しないコードのみを書くことができる
つまり問題を起こす実装継承とならず
Rustでは健全な継承が実現されている
669 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 10:55:22.37 ID:6tgHXwg2.net]: 複オジの耳に念仏
まさに>>630
670 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:03:01.23 ID:aq0ZJn08.net]: デフォルト実装の制限のかけ方が成功の肝かな
トレイトなので各型のメンバーフィールドには一切アクセスできないため実装継承が上手く回避されてる
671 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:27:47.73 ID:Qb4+6aEo.net]: 「実装は継承しているけど実装継承ではない」ｗ
672 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:38:02.68 ID:0gbetOzk.net]: 複オジ論法は無敵だな
673 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 11:49:10.64 ID:aq0ZJn08.net]: >>657
他の型の実装に実装が依存することが実装継承と呼ばれてる
674 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 13:25:29.85 ID:QAb8fFud.net]: 継承の本当の問題は、LSPを満たさない部分型関係を作ってしまいがちということ
他の型の実装に依存するのが良くないというのはDIの話で、直接は関係ない
675 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 13:56:53.31 ID:0on8bWSc.net]: うそん
crate製作者サイドでCargo.toml内の
他のcrateへの依存関係の描き方がいい加減だと
割りと頻繁に詰む
人間が追跡して治して行けば使えなくもないが
cratesは破綻する可能性がある
676 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 15:03:24.53 ID:HJF+848e.net]: クレートdownloadでか過ぎ

どうみてもどんぐりです
ばいばいおさるさん
ころころす
677 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 17:42:30.38 ID:NWN6grys.net]: >>660
クラスを用いる言語では必ず満たすべきLSP(リスコフの置換原則)が頻繁に守られていない現実から
GoやRustなどモダンな言語はクラスそのものを廃止して改善したわけだ
他の型の実装に依存するのが良くないのも当たり前の話でそこは各型へ移譲しなければならない
678 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 18:36:24.36 ID:jkhWqaDw.net]: >>663
LSP全然理解してないんやな
クラスの有無とか全く関係ないぞ
679 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 18:41:05.12 ID:BP+Tby1x.net]: >>657
ジワジワくる
680 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 19:00:42.33 ID:lBXxnkJT.net]: >>657が実装継承とは何かすら理解できていなくて草
681 名前：デフォルトの名無しさん mailto:sage [2024/07/08(月) 23:32:15.60 ID:HOKpNi7I.net]: 所有権といい継承といいLSPといい
某オジは抽象概念を捻じ曲げるスキルが高すぎだろ
682 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 00:42:48.79 ID:m6Akkl5N.net]: >>660
LSPは派生型がその基底型を継承する時その振る舞いは同じで代替できるという当たり前な話なんだが
クラスはこの件でも欠陥があるため意識してプログラムを書かないとLSPに反してしまう
Rustはクラスがなくトレイトは枠組みだけで基底型ではないためLSPは全く関係ないぞ
683 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 02:24:36.95 ID:ZNKPIxXk.net]: >LSPは派生型がその基底型を継承する時その振る舞いは同じで代替できるという当たり前な話なんだが

0点
684 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 11:02:57.90 ID:Gz8hLZg7.net]: 書けば書くほど無知をさらしてしまう複製オジさん草る
685 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 12:31:29.17 ID:B8U2Xwe0.net]: >>664
対象となるものはクラスしかないよね
686 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 12:39:43.65 ID:YflJELWV.net]: >>668
φ(x) を型 T のオブジェクト x に関して証明可能な性質とする。このとき、φ(y) は型 T のサブタイプ S のオブジェクト y について真でなければならない。

φは主に事前条件・事後条件・不変条件で、言語によっては例外条件も入ってくる。
この観点からはRustのTraitは力不足。なんでLSPを引き合いに出せるのかわからん。
687 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 12:57:46.02 ID:aoAam1/W.net]: >>672
自分でそれを書いておいて理解できていないのかよ
そこに明記されてるようにTもSもオブジェクトを持つ具体型についての話だ
Rustのtraitは具体型ではないため関係ないぞ
そしてtraitを実装する各型の間にはサブタイプの関係はないためそこも対象とならない
そこを理解できずに「RustのTraitは力不足」とデタラメを吹聴するのは恥ずかしい
688 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 13:01:26.64 ID:YflJELWV.net]: >>673
事前条件とかはどこ行ったの？
689 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 13:20:56.23 ID:aoAam1/W.net]: >>674
φ(x) のxはオブジェクトと明記されてるのが見えないのかね
さらにSはTのサブタイプと明記されている
Rustのtrait自体はオブジェクトを持たない
さらにtraitを実装する二つの型同士にサブタイプの関係は生じない
つまり対象外でφが存在しないため事前条件も何もない
690 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 13:35:41.29 ID:YflJELWV.net]: >>675
＞明記されてるのが見えないのかね
＞Rustのtrait自体はオブジェクトを持たない

それは「RustのTraitはLSPと関係ない」と言いたいの？

＞φが存在しないため事前条件も何もない
事前条件も何も表明できないのは「力不足」そのものですな。
691 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 14:43:14.46 ID:Tc+iYmTn.net]: リファクタリングするとき
プログラム(CPU)の動作の副作用は起きないけど
コーディングの変更に対して副作用が大き過ぎるというか広過ぎる
692 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 15:17:32.29 ID:l7dFkPpL.net]: >>673
マジでLSP全然理解してないんやな
LSPは具体型かどうかなんて全く関係ないぞ
693 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 15:20:15.91 ID:aoAam1/W.net]: >>676
LSPに明記されている前提すら満たさない異なるものであるため
「RustのTraitはLSPと関係ない」で合っている
LSPが対象としている遺物における諸問題に悩まされずに済むように
新たな視点で整理されたより良いものとしてRustのTraitが提供されている
694 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 15:28:08.29 ID:aoAam1/W.net]: >>678
LSPは具体型のみが対象
抽象型を対象にしようとしても適用するにはそのいずれかの具体型となる
695 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 17:53:13.80 ID:uNqr/AfO.net]: https://x.com/shuzaibusoku7/status/1809567812555542920
リアル複おじ
696 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 20:23:57.43 ID:YflJELWV.net]: >>679
RustとLSPが関係ないのなら、LSPを引き合いに出すのは大嘘か。
知ってて言っているなら詐欺師だな。

そもそもTraitでpanic禁止にできない時点で「LSPが対象としている遺物における諸問題に悩まされずに済む」というのも大嘘だしな。
697 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 20:49:10.75 ID:sTXYSGuF.net]: 簡単な話だよな
オブジェクト指向プログラミングで
例えばクラスを使うと
LSPに違反する二つの型のコード例を容易に作れてしまう
つまりクラスは本質的に欠陥品なんだよ

Rustのトレイトを使うと
LSPに違反する二つの型のコード例を作ることができない
つまりRustのトレイトは優れた方式なんだよ
698 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 21:07:20.42 ID:YflJELWV.net]: >>683
あるトレイトでpanic2を禁止しようとしました。事前条件(あるいは例外条件)でnopanicとしたかったけど、そんなのは無いのでとりあえずデフォルト実装でpanic禁止にしました。
しかしトレイトユーザーはそんなのお構い無しにunsafe rustでpanicを使います。ついにpanicが発生してシステムダウンしました。

LSPでケアしている問題はRustのTraitを使っている限り発生しないんじゃないんだっけ？
699 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 21:56:05.19 ID:sTXYSGuF.net]: Rustのトレイトは優れているため
LSPに違反するコード例を作ることができないんだよ
もしRustに文句をつけたかったら
LSPに違反する二つの型のコード例を作って示してごらん
Rustで違反例を作るのは不可能だよ
700 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:08:43.14 ID:ZNKPIxXk.net]: >>685
Rustに文句をつけたいとかではなく
>>660でLSPに言及された途端に実装継承とか言わなくなって「最初から自分はLSPを理由に継承のダメさを語ってましたけど」って態度でイキリ倒してるの(+結局理解してなさそうなの)がバカにされとるんやで
701 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:36:56.01 ID:YflJELWV.net]: >>685
>>684みたいに、
トレイトがpanicを禁止したいのに、ユーザーのトレイト実装がpanicを返す
というのはLSP違反だろ。
702 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:44:26.63 ID:loMF79su.net]: LSPはそんなことを要求していないよ
LSPをちゃんと読んで理解しようね
703 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:50:55.17 ID:aoAam1/W.net]: >>686
クラスは様々な問題点を抱えている
クラスでは実装継承となるため異なる型同士に不必要に過度な依存関係をもたらす硬直性も問題点の一つ
クラスはLSP(リスコフの置換原則)を満たさないプログラムが量産されてしまう問題点も別の一つ
どちらの問題点もRustならtraitを使うため問題が起きない
704 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 22:52:12.26 ID:j8eVmrRh.net]: 猿ども落ち着いてください！

ここで論破合戦したところでなんの得にもなりません
705 名前：デフォルトの名無しさん [2024/07/09(火) 22:57:23.83 ID:/lHavWP5.net]: >>685
リスコフの置換原則は設計的な原則だから言語仕様で違反を防ぐことはできないぞ
悪名高い長方形・正方形の問題はトレイトがあっても起こり得る

trait Rectangle {
　fn set_width(&mut self, width: i32);
　fn set_height(&mut self, height: i32);
　fn width(&self) -> i32;
　fn height(&self) -> i32;
　fn area(&self) -> i32 { self.width() * self.height() }
}

struct Square { len: i32 }

impl Rectangle for Square {
　fn set_width(&mut self, width: i32) { self.len = width; }
　fn set_height(&mut self, height: i32) { self.len = width; }
　fn width(&self) -> i32 { self.len }
　fn height(&self) -> i32 { self.len }
}

fn func(x: &mut impl Rectangle) {
　x.set_width(3);
　x.set_height(4);

　// xが長方形であれば以下が成り立つはずだが、Square型を渡された場合に失敗する
　assert!(x.area() == 12);
}
706 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:17:09.97 ID:dptasXVA.net]: >>691
長方形がトレイトで正方形が構造体とか意味不明なんだが他の形はどっちにするんだ？
おかしいだろ
707 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:22:06.46 ID:J+Fyw0mO.net]: >>691
トレイトは機能を表します
2つの異なる長さを持つ(受け取る)機能を定義しているのならば
正方形はその実装型にはなりえません
708 名前：デフォルトの名無しさん [2024/07/09(火) 23:24:11.46 ID:KAvgjhF7.net]: >>692
IRectanble トレイトとかに読み替えてくれ
これは設計的に問題のある例を恣意的に示しているので不自然な点はあるけど、意図は伝わると思う

分かる人は分かると思うけど、問題は「そもそも正方形はwidthとheightという2つの値を扱うインタエースを持つべきでない」というところなので、Rectangleトレイトを作った時点で破綻している
けどそれは設計の問題なので、トレイトという仕組みによってコンパイラが防げるものではないということ
709 名前：デフォルトの名無しさん [2024/07/09(火) 23:30:16.52 ID:KAvgjhF7.net]: >2つの異なる長さを持つ(受け取る)機能を定義しているのならば
>正方形はその実装型にはなりえません
論理的にはそう
でも実際にそういうコードを書けばビルドは通る

>>685 で
>LSPに違反する二つの型のコード例を作って示してごらん
>Rustで違反例を作るのは不可能だよ
とあったので、これはその反例として示した
このような問題は設計の問題であり、まずい設計をする人が使えばRustでも問題は起こり得るということを言いたい
710 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:35:35.51 ID:h2DmPYHm.net]: >>691
君はLSPを理解できていない
LSPはis-aの関係を持つ二つの型に対して遵守すべきルールだ
Rustのtraitとその実装型はis-aの関係ではなくhas-aの関係を持つ
したがってtraitとその実装型は明らかにLSPの対象外となる
711 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:40:48.87 ID:h2DmPYHm.net]: >>695
LSPに違反する二つの型はis-aの関係を持つsupertypeとsubtypeでなければならない
>>691はhas-aの関係なのでLSPに違反する二つの型のコード例とはなっていない
712 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:56:35.46 ID:ZNKPIxXk.net]: >Rustのtraitとその実装型はis-aの関係ではなくhas-aの関係を持つ

すげーのが出てきたなこりゃｗ
713 名前：デフォルトの名無しさん mailto:sage [2024/07/09(火) 23:59:12.82 ID:loMF79su.net]: LSPはis-a関係に対して守るべき原則
has-a関係に対してLSPの適用は論外
コード>>691はLSPの違反例となっていない
714 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:09:07.13 ID:H4rrLaXL.net]: メンバ関数名をそのままtraitの名前にしちまえば
そのメンバを持つ者とtraitの関係はhas-a
715 名前：デフォルトの名無しさん [2024/07/10(水) 00:10:24.05 ID:HryWiaEt.net]: 過去に見た (rust以外の) プロジェクトの失敗例だと
・もともとFooというクラスがあった
・新しく作るBooクラスについて、Fooクラスと同じように扱えれば既存コードをあまり変更しなくても済むぞ！と誰かが気づいた
・その人物は Foo クラスのメソッドを元に IFoo インタフェースを定義し、それを Foo と Boo に実装させた
ことから混沌としたコードが生まれた例がある

この失敗をやらかした人は、Rustでも同じように「既存の Rectangle クラスを元に IRectangle トレイトを作り、それを Rectangle と Square に実装させる」ことをやりかねない

Rustではそれが不自然なパターンになりやすいし、起こりにくくはあるけど、本質的には設計の問題
716 名前：デフォルトの名無しさん [2024/07/10(水) 00:29:11.77 ID:HryWiaEt.net]: 「Rustを書く人はみんな賢いからそのような問題は起こさないはずだ」というなら話は別たけど
実装者の設計能力は言語仕様によって担保できるものではない
717 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:33:23.92 ID:L/ekmjSC.net]: >>701
それらインタフェースやトレイトを用いている時点でLSPの対象外となっている
LSPを満たす必要がないどころかそんな制限があったら支障が出る
>>691のコードをLSP違反例として出してきたのは明確に間違い
おバカな設計例としてならば理解する
718 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:35:49.38 ID:L/ekmjSC.net]: >>702
おバカな設計を言語仕様で防げるなんて主張は誰もしていない
あなたが勘違い思い込みで暴走している
719 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:36:32.00 ID:NGyo+F/O.net]: LSPを全く理解してないばかりか
サブタイピングも理解しとらんのやな
よう継承継承言うたなぁｗ
720 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 00:53:28.80 ID:ur6BKR72.net]: クラスが問題だらけの欠陥品なことが災いを招いてるよね
モダンなプログラミング言語の多くがクラスを捨て去ってくれて感謝
721 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 01:13:16.99 ID:1XduDtMr.net]: >>688
>>679の言う「LSPが対象としている遺物における諸問題に悩まされずに済むように」するためには必要なんだよ。
LISKOVのA behavioral notion of subtyping でも「include exception」と言っているだろ。

まぁ、panicが例外にもなれないそびえ立つクソだからRustから排除すべき、と言うなら同意するが。
722 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 01:26:45.94 ID:UJdk5M3g.net]: >>707
LSPはsuperclassとsubclassといったような関係を持つ型同士について満たすべき話が書かれてるんよ
その前提を無視してpanicがどうこう言い出してるからズレとるんよ
723 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 01:45:22.45 ID:1XduDtMr.net]: >>708
それを言うなら>>682で言っている通り、RustのTraitでLSPに言及するのが大嘘なんだよ。

RustのTraitは同じTraitでも簡単に異なる振る舞いを実装できる(panicみたいな致命的な振る舞い含め)のに、「LSPが対象としている遺物における諸問題に悩まされずに済む」とかの大嘘が出てくるのは何ともアホらしい話。
724 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 02:13:28.47 ID:1XduDtMr.net]: >>698
RustのTraitとImplの関係はまさしくsubtypeだしis-aの関係なのにな。「継承しなければsubtypeじゃないしis-aにもならない」と間違って覚えているんかね。
725 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 02:30:31.13 ID:GS4KrVsy.net]: どこかで聞きかじっただけの「継承は悪」に辻褄を合わせようとしてどんどん変な理屈を積み重ねているだけでしょ
726 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 02:33:48.76 ID:H5PXuDT2.net]: >>707
LSPでは例外を返すなら基底型で返す例外とそのサブタイプのみに限られるとしか言及していない
例外で値をキャッチできなくなることや値を返す抜け道になることを防ぐためだ

ちなみにRustのpanic!では値を返すことはできなくてpanicメッセージのみ
そして普通のプログラムでpanicをキャッチすることはない点など前提が全く異なる
Rustで従来の例外を扱うケースはpanic!を使わずにResultの返り値で返す
したがってpanic!はLSPで出てくる例外の話に該当しないだろう
727 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 03:06:35.71 ID:mzDH1NTP.net]: >それらインタフェースやトレイトを用いている時点でLSPの対象外となっている
間違ってるよ
インターフェースだろうがトレイトだろうがサブタイピングは成立するよ
サブタイピングが成立すれば当然LSPの対象範囲だよ

>>691の例もLSPの違反例としては合ってるよ
間違った継承の使い方の例としてよく使われてるよね
728 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 04:10:08.62 ID:xXJVwGE7.net]: >>684
>panic禁止にしました。

たとえno_std環境であろうとpanicは禁止にできない

>unsafe rustでpanicを使います。

panicを引き起こすのも扱うのもunsafeを必要としない

>panicが発生してシステムダウンしました。

panic発生がそのままシステムダウンではない
何ら特別な設定をしない標準状態でもスレッド内で起きたpanicはエラーとして返るだけで他のスレッドは動き続ける
729 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 07:01:39.33 ID:H4rrLaXL.net]: >>710
型クラスのinstanceであると宣言すればsubtypeじゃないのは自明だぜ
じゃあtraitをimplすると宣言したら
自明だった問題が突如として最先端の未解決問題に変化するのか？
しないでしょ
同じでしょ
730 名前：デフォルトの名無しさん [2024/07/10(水) 07:02:08.59 ID:HryWiaEt.net]: >>704
ずっと「オブジェクト指向言語のクラスが抱えている問題はRustでは起こらない」と主張してる人がいるでしょ
それに対して、そんなことはないよと言ってるだけ
731 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 07:35:50.92 ID:1hn7S5X0.net]: >>716
あらゆる問題が解決されたという話は出てないでしょ
クラスが抱えてる問題でRustによって解決されてる様々な例が出ているだけで
732 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 08:46:54.18 ID:1XduDtMr.net]: >>714
だからLSPが対象としている諸問題はRustじゃ解決しないと主張しているんだよ。

>>715
implの実装次第なのに、
「LSPが対象としている遺物における諸問題に悩まされずに済む」と言っているアホが居るのよ。
そんな機能はRustのTrailには無いわな。

>>717
「遺物における諸問題に悩まされずに済む」と言っているアホが居るのよ。しまいにはRustとLSPは関係無いとか言うし。
そんなわけ無いだろと主張している。
733 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 12:00:16.62 ID:GhKm8r1f.net]: >>718
そのアンカ先は全部複オジだろ
LSPも知らない、サブタイピングも知らない、継承で起こりうる簡単な問題も知らない
にもかかわらず知ったかぶりして嘘を並び立てる
こんなやつがそうそういるわけがない
734 名前：デフォルトの名無しさん [2024/07/10(水) 12:37:44.86 ID:1YSFCzN+.net]: キチガイは1人見かけたら10人はいると思え
735 名前：デフォルトの名無しさん [2024/07/10(水) 13:29:52.02 ID:kPG9kWdt.net]: >>701
そのやり方がなぜ悪いのか理解できませんので、教えてください。
例えば、C++だと、以下の様にするのも別に悪いやり方ではないような
気がするのですが。
class Number {・・・};
Number add(Number &a, Number &b);
Number mul(Number &a, Number &b);
class Integer : public Number {・・・};
class Rational : public Number {・・・};
736 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 13:32:41.05 ID:2GPD5dJ4.net]: ChatGPTってモノシリなんですね？
737 名前：デフォルトの名無しさん [2024/07/10(水) 13:34:42.29 ID:kPG9kWdt.net]: >>721
改めて見てみると、add()やmul()の戻り値にNumberの実態を返しているのがおかしい気もしますが。
IntegerやRationalにadd()やmul()を仮想関数として定義するのが良いのかもしれません。
そのような点で改良の余地が沢山ありそうです。
738 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 13:47:33.33 ID:2GPD5dJ4.net]: >>720
色んな板の色んなスレをみて来ているが
どこにでもいるのは事実
739 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 14:42:18.00 ID:H4rrLaXL.net]: 10人いると思ってる人自身が11人目になりやすいから気をつけなよ
数値の計測が抱えている問題は、そもそも計測していない人には起こらない
740 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 15:49:38.80 ID:WriLZMcZ.net]: >>721
add(integer, rational)できる？
741 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 16:24:23.57 ID:2GPD5dJ4.net]: ミイラとりがミイラになるのは昔から
742 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 16:42:16.40 ID:aw6hROvm.net]: >>712
>例外で値をキャッチできなくなることや値を返す抜け道になることを防ぐためだ
違うよ
勝手な想像でLSPを誤解釈しないで

substituteされる型Tに対して定義された仕様上(契約上)の振る舞いを
substituteする型Sが満たしてなければLSP違反
つまり仕様上panicを禁止したトレイトの関数を
panicする関数でimplしたらLSP違反
743 名前：
LSPではあくまで”仕様上定義された振る舞い”が問題 []: [ここ壊れてます]
744 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 18:28:13.04 ID:/bwWoePd.net]: >>728
panicを禁止という概念も方法もなく不可能だよ
何をしたいの？
745 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 21:04:08.95 ID:H4rrLaXL.net]: catchするという対案がない
対案との比較が抱えている問題はそもそも対案がない言語では起こらない
746 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 21:42:13.36 ID:DHf/HCo5.net]: >>729
そいつはRust叩きで連投していた>>684
panicを禁止できると思い込み
unsafeを使うとpanicできると思い込んでいる
747 名前：デフォルトの名無しさん [2024/07/10(水) 22:01:49.20 ID:HryWiaEt.net]: >>721
「インタフェースを定義し、それに基づいて実装する」という設計なら問題ないのだけど、
これは「あるクラスに依存していたコード群が新しいクラスでも動くようにするため」という発想になっており、大規模な開発だとこのやり方はだいたい失敗するよという話

例を書きづらいけど、例えば「A社製の装置を制御するアプリ」があったとして、
新しく「B社製の装置も制御できるようにする」という追加の開発案件があったとする。
この時点ではまだADeviceControllerは抽象化されておらず、A社装置の仕様に強く依存したクラスであるとする。
これを「ADeviceController が持つメソッドを IDeviceController として取り出し、それを BDeviceControllerにも実装させる」とすると確実に事故る。
「B社装置にだけある機能Xを呼びたい」「A社装置にあった機能YがB社装置にはない」といった違いを吸収しきえれず、インタフェースがぐちゃぐちゃになったり、「呼んでも何もしない」とかの形で誤魔化したり、呼び出し元でサブクラスの判定が必要になったりする

こうならないようにするには
a. 具体的な機器に依存しない、機器の振る舞いを適切に抽象化したインタフェースを定義する
b. 代数的データ型を使う
という方法があり、 Rust では b. の方法も使いやすいので、個人的にはそこが良いなと思う
748 名前：デフォルトの名無しさん [2024/07/10(水) 22:15:46.44 ID:b9m+kH0p.net]: 設計が悪いといえばその通りなんだけど、そのせいでインタフェースが崩壊しているプロジェクトは実際にあるし、RustやGoが継承を廃止した理由の一つでもあると思う
クラス継承だとこの問題はもっと簡単に起こりやすい
前述の例は (あくまでも見かけ上は) インタフェースを定義しており、クラスを継承してるわけではないので、Rustのトレイトでもやろうと思えば起こるけどね
749 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 22:19:25.73 ID:FlmWdBd4.net]: 言語を選ぶにあたって継承の有無は選択肢に入らんし正直言ってどうでもいいわ
代替手段があるのにいつまで言ってんだ
750 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 22:32:22.87 ID:dGMDZq55.net]: >>729
仕様を定義するという簡単なお話がほんとにわからないのかな？

panicを例にすると頭がパニクるみたいなので
リスコフの論文にあるFIFO/LIFOの例で言い換えると
仕様としてLIFOの振る舞いを要求するトレイトの関数を
FIFOの振る舞いで実装したらLSP違反ってこと

簡単なお話でしょ？
751 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 22:40:16.17 ID:H4rrLaXL.net]: 既に言語を選んだのにまだ、is-aとhas-aどっちにするか選べとか
catchするかしないか選べとか
言語の内部でいつまでも選択が繰り返されるシステムが謎なんよ

いつまで言われるかといえば謎が解けるまでだよ
752 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 23:21:18.85 ID:visgGGe9.net]: >>732
それは共通インターフェースと特定装置にしかないインターフェースをそれぞれ別で用意すべきだと思う
拡張メソッドや拡張トレイトも活用する

ただA社装置もB社装置も1つの共通したコードで扱うなら
サブクラス判定ではないにしても呼び出し元での分岐は何かしら必要
753 名前：デフォルトの名無しさん mailto:sage [2024/07/10(水) 23:44:27.81 ID:6pwTfhEs.net]: >>733
RustやGoは違う方法で継承を行っているというだけで継承を廃止したというのは誤解
わざと誤解
754 名前：させてるという面もあるにはある []: [ここ壊れてます]
755 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 00:29:09.09 ID:dTTJ6k+i.net]: クイズ
JavaScriptのプロトタイプチェーンはis-a？
それともhas-a？
756 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 00:30:41.75 ID:sJ7PGs8/.net]: >>732
一般的に何らかの上位層と下位層があるときに
Rustではその界面にtraitを置いて
上位層はそのtraitを利用する側
下位層はそのtraitを実装する側
とSILIDのDIP (Dependency Inversion Principle)にするのがそのa.だね
もしクラスでやるときは抽象化を徹底した上で色んな注意が必要になるところ
Rustは自然にコーディングできてありがたいね
757 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 01:01:01.84 ID:sJ7PGs8/.net]: スマソ
SILIDはSOLIDのタイポ
758 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 01:26:06.15 ID:sLOW5r2m.net]: >>740
インターフェース知らないの？
759 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 01:37:36.53 ID:sJ7PGs8/.net]: >>742
インタフェースは各言語で付加仕様がバラバラ多種多様だから慎重に言うと
それ自体はフィールド変数など持たず完全に抽象化できつつ
実装必須メソッドとデフォルト実装提供メソッドがサポートされて
その中で利用可能な他のインタフェース(またはtrait)群による制約ができて
となるとどの言語が残るかな
760 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 03:34:06.04 ID:huEwUyFV.net]: それはたぶんDじゃなくてIかな……
761 名前：デフォルトの名無しさん [2024/07/11(木) 09:53:46.09 ID:TzM2Jqw+.net]: https://doc.rust-jp.rs/ 終了の件
762 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 11:33:08.04 ID:gcQpVY2c.net]: >>744
DもIも両方関係あるよ
763 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 11:36:08.08 ID:gcQpVY2c.net]: >>743
インターフェースが使えるメジャーな言語は全部残る
C#, Java, Kotlin, Swift, TypeScript, Dart
764 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 11:46:30.35 ID:ITTQebkb.net]: ʕ◔ϖ◔ʔ
765 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 12:31:18.41 ID:QtPgEU0q.net]: >>747
ウソはあかん
766 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 13:53:08.83 ID:gabJiib7.net]: >>747
サーバー用途で強いJavaは残るね
Kotlin/Swiftもモバイルアプリのネイティブ言語として残る
TSはJSで十分っていう風潮が漂いつつあるけどまあ残るだろう
死ぬのはC#とDartかな
767 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 14:12:48.49 ID:0oGtZVd6.net]: LSPで嘘ばっかりついてたのがバレたから
またしょうもない話をはじめてごまかそうとしてるのか
いい加減にしろよ
768 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 16:22:35.45 ID:o6wwWo1Z.net]: LSPに書かれていることすら読まずに
RustのトレイトがLSPの対象だと言い張ってたもんな
769 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 16:57:46.28 ID:acwFdQNv.net]: PartialOrdとPartialEqの一貫性とかLSPっぽいけど
Substitution（置換）とはちょっと違うんだよな
無理矢理Sに当てるならSurrogation（代用）あたりか
これをLSPに含めるかは定義重視vs意味重視で意見が分かれそう
770 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 17:15:40.81 ID:HnhcW2rv.net]: LSPはsupertypeのインスタンス(オブジェクト)とsubtypeのインスタンスの振る舞いを比較してそこで満たすべき原則を挙げていますから
Rustのtraitをsupertypeとしてみてもそのインスタンスが存在しないため振る舞いの比較ができないですね
traitはLSPとは関係ない立ち位置にいます
771 名前：デフォルトの名無しさん [2024/07/11(木) 20:33:40.77 ID:eOImp5ti.net]: ごちゃごちゃ難しいこと考えてるうちにエンバグしたりなんかして。
772 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 21:02:05.21 ID:qBSAH7HU.net]: >>750
サーバー用途こそJavaはRustとGoに蹴散らされて終わるだろ
773 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 21:30:58.09 ID:wPVHCKh0.net]: 実際のところRustはサーバーサイドで使われてるの？
774 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:25:27.54 ID:A0mL7vqg.net]: 実際は派生クラスの方が支持されていたとしても基底クラスを蹴散らしてはならない
とLSPは言っている
775 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:35:40.65 ID:Z3SFRt47.net]: >>757
使われてないよ
776 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:47:57.53 ID:Wdw77EAw.net]: >>757
Rust利用のトップがウェブのサーバー側
この件は過去スレでも何度も出ているので興味あるなら見るといいよ
その理由も明白でリソースコスト削減が最も効くため
777 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 22:50:39.98 ID:wG+w8SXo.net]: サーバーは常時稼働させるものだからねえ
778 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 23:16:00.08 ID:liPsU6bJ.net]: >>757
GAFAMとかCloudflareとかトラフィックの多いとこに入ってるから誰もが必ずお世話になってる程度には使われてる
日本でサーバーサイドの仕事が沢山あるか、という意味ならそんなことはない
779 名前：デフォルトの名無しさん mailto:sage [2024/07/11(木) 23:24:11.59 ID:b01V4j67.net]: 世界中で着実にRustへ置き換わっていってるね
特にクラウドを利用しているとランニングコストに直結するので
780 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:13:00.93 ID:0qGKBZrU.net]: >>753, 754
トレイトの場合はLSPで言うsupertypeやsubtypeになるのは
トレイトを利用して作られるimpl Traitやtrait objectの型だよ

PartialOrd/PartialEqやFn/FnMut/FnOnceのように
supertrait/subtraitの関係にあるやつも便宜的にトレイトで互換性が語られるけど
実際はそれらを利用して作られる型についての話なのと同じなんだよ
781 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:16:45.77 ID:U8/iJiIO.net]: >>764
真面目に相手してあげるの偉いな
782 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:19:01.43 ID:iZsWh24v.net]: >>764
いいえ
traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため
親となるsupertypeの具体的な型はありませんはありません
783 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:19:49.06 ID:iZsWh24v.net]: >>764
いいえ
traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため
親となるsupertypeに相当する具体的な型はありません
784 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 00:47:16.73 ID:KyXC0KGT.net]: トレイトにはフィールド変数が一つもなくてメソッドも各個別型で実装されるものだから事前条件・事後条件など比較もできなくてLSP適用は無理でしょ

>>764
supertrait/subtraitの場合に例えばある構造体についてそのインスタンスはどちらも同一になるからLSPの前提である二つのインスタンス間での差は論じられないでしょ
785 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 09:52:35.34 ID:bw8b12Bg.net]: >>757
Rustは殆どどこにも使われてないよ
786 名前：デフォルトの名無しさん [2024/07/12(金) 10:23:09.62 ID:LuKbokrL.net]: 「C言語は分かる。機械語も分かる、回路もわかる。30万払うからRustのメモリ安全のからくりをサクッとレクチャーしてくれ」
みたいなニーズがあっさり無料で満たされているべきだと思うんだ
787 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 10:57:31.20 ID:KyXC0KGT.net]: 誤解は色々あるけど「努力すれば必ずゼロコストになるカラクリ」が
あると思ってるならそれが誤解だね
クイックソートやハッシュテーブルと同じく、最悪の場合のコストは低くない
788 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 11:16:56.09 ID:LuKbokrL.net]: 間違ってたら指摘してくれ

メモリは唯一の所有者を持つ
所有者たる変数がスコープを抜けた時、もしくは所有者たる変数に他の値が代入された時、メモリは自動的に解放される
Rustの、メモリに関する様々な文法はひとえにレキシカルライフタイムのためである
レキシカルライフタイムすなわち字句的寿命は、プログラムを走らせなくともコンパイル時に変数の寿命が把握できる仕掛けである
メモリの使途に矛盾が発生しているとき、Rustコンパイラはエラーを吐く
789 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 11:28:19.38 ID:LuKbokrL.net]: そもそも動的メモリ確保一般を知っていますかって話で、
この質問にイエスと答えられる人は横着ができるべき
790 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 13:01:13.97 ID:KyXC0KGT.net]: >>771
Rustのゼロコスト抽象化はそういう意味ではなくてRustの様々な抽象化仕様を実行時の追加コストゼロで実現していることでしょ

>>772
値がムーブされないままスコープが尽きたらデストラクタが自動で呼ばれるだけでしょ
だからRcのように参照カウンタを用いて共有ownershipを提供する仕組みもあるよ
791 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 13:21:18.68 ID:KyXC0KGT.net]: 唯一の所有者が存在することと所有者の情報を誰でも取得できることを
区別するのは少し難しい
大谷の家が実在することと住所を公表できることを区別できない人もいるかもしれない
792 名前：デフォルトの名無しさん [2024/07/12(金) 14:02:34.71 ID:HU5SDXKx.net]: 「A が Bの継承クラスであること。即ち、C++で
class A : public B {・・・};
と書くのは『A is B』である時が良い事が多いですよ」
という説が有りますけれど、
「多い」というだけだと理解してたんですが、このスレの人には、このルール
を徹底徹尾適用できる言語を夢見ておられるようですね。
793 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 14:20:30.92 ID:KyXC0KGT.net]: ここでID何度か被ってきたけどポエムの人とID被ったのは初めて

>>776
クラス継承はメリットが少なくデメリットが多いと長年の共通体験で判明してそれが共通認識となっているから
様々な異なる方針のモダンな言語たちがクラス廃止の点では共通方針となっただけでしょ
794 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:35:12.29 ID:4qvv2DeJ.net]: 何気なく cargo update すると後悔する orz
795 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:44:29.48 ID:4qvv2DeJ.net]: GAFAM は存在しない
今は GAMAM
796 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:46:16.40 ID:4qvv2DeJ.net]: >>772
drop(hoge)
797 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 15:49:17.77 ID:4qvv2DeJ.net]: >>773
Box
Rc
Arc
Cell
RefCell
OnceCell
Pin
798 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 17:11:30.65 ID:LuKbokrL.net]: >>780
サンキュー

>>781
そのあたり全然勉強してない
「相互に参照し合うあうメモリは持てません。それを制限してあまりあるメリットを提供します。どうしてもやりたい人のために別口を用意しました」
という事実が重要
799 名前：デフォルトの名無しさん [2024/07/12(金) 20:20:08.14 ID:0tYdINiS.net]: Rust製コードエディター「Zed」がLinuxにようやく対応
Windowsサポートにも期待

ttps://forest.watch.impress.co.jp/docs/news/1607906.html
800 名前：デフォルトの名無しさん [2024/07/12(金) 20:23:46.34 ID:0tYdINiS.net]: 個人利用は無償～JetBrainsがRust向けIDE「RustRover」を一般公開
メモリ安全性を保障したプログラミング言語「Rust」の開発に特化した統合開発環境

ttps://forest.watch.impress.co.jp/docs/news/1607747.html
801 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 20:46:42.78 ID:KyXC0KGT.net]: 別口を用意するとは？
RustらしくないRustを用意することかな

もし日本語らしくない日本語が何か成果を出したら
日本語らしさを学習したAIに都合が悪い
802 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 21:35:52.40 ID:VV8L6PZC.net]: >>784
慣れの問題なんだろうけど
vscodeがいい…
803 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:05:28.85 ID:LuKbokrL.net]: >>785
参照カウンタ等がその別口
逆に聞くけど全てを参照カウンタで書かないのはなぜ？
804 名前：デフォルトの名無しさん [2024/07/12(金) 22:12:50.70 ID:VeLgD+zy.net]: >>781
RcやBoxは分かりやすいけどStringやVecも動的確保だよね、ということに気付いてない人もいるかも？

Rustが良いのはムーブが基本なおかげで意図
805 名前：せぬメモリコピーが起きないこと 所有権を他に渡す (ある構造体から別の構造体にか、あるコンテナから別のコンテナにとか移動する) 際にコストが発生しない C++は逆で明示的に move しないと意図せぬコピーが起こる []: [ここ壊れてます]
806 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:30:09.43 ID:KyXC0KGT.net]: >>787
強制されてないから
嫌なら使わなければいい
807 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:37:23.69 ID:LuKbokrL.net]: 電気電子板の人が、Rustの特集やってるインターフェース誌を買って読んだけどわからんかったって言ってたよ
808 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 22:52:07.26 ID:LuKbokrL.net]: >>789
俺はそんなことしないよ
全てを参照カウンタなんて使わずに書かない理由を探る
809 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:03:04.47 ID:IhFaP3QA.net]: >>787
C++で常にshared_ptrを使うと遅い
参照カウンタを利用しがちなSwiftやNimは遅い
810 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:08:24.73 ID:LuKbokrL.net]: 参照カウンタ自体は全然新しくない
Rustがそれを無くせない理由が知りたい
811 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:24:14.35 ID:LuKbokrL.net]: 複数の所有者がいる場合に参照カウンタが有効なのは分かる
難しいのは循環参照
参照カウンタで何が書け、何しか書くべきでないか
812 名前：デフォルトの名無しさん [2024/07/12(金) 23:48:00.71 ID:VeLgD+zy.net]: >>793
メモリ安全性を提供するため
オブジェクトを共有するのに「所有権は1人だけが持ち、他はそれを参照する」仕組みだと、すでに実体が消えてるオブジェクトを参照する問題が起こり得る
Rustでは、そのようなオブジェクトは参照カウンター付き (RcやArc) にするか、ライフタイムにより「寿命の短いものが寿命の長いものを参照している」ことを示さない限りコンパイルが通らないようにすることで安全性を保証している

逆にC++は参照カウンターなしでも共有できるけど正しく実装しないとメモリ関連のバグを引き起こす
この手のバグはセキュリティの問題になり得る問題を特定しにくい等の厄介さがあるから、Rustはそれをコンパイル時にできる限り防ぐという考え
813 名前：デフォルトの名無しさん mailto:sage [2024/07/12(金) 23:56:48.21 ID:n+FrpY/U.net]: 同一スレッド内の別タスクと共有する時にRcを使う
別スレッドや別スレッドになりうる別タスクと共有する時にArcを使う
814 名前：デフォルトの名無しさん [2024/07/13(土) 00:02:12.31 ID:mV5TIlCk.net]: 親子関係のようなオブジェクト間で相互参照するならWeakを使う
これはRcやArcから作るもので、「メインの所有者とそれを弱参照する共有相手」の関係になる
Weak側は相手がまだ存在することを確認できないと参照できないというもの
815 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 00:46:50.81 ID:UG7jOJ2R.net]: Rust の所有権システムは機械的に静的検証が可能なように設計されている。
しかし Rust のルールでの機械的静的検証で安全だと確信できないが実際には安全というケースは
ごく普通にあり、その内の典型的なものは実行時のチェックで補えるようにライブラリが整備されている。
816 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 02:23:43.98 ID:k/Plwdnm.net]: >>787
全てをRcで扱って渡すときはRcをclone()して渡せばライフタイムを気にしなくて済むが
参照カウンタとその増減のオーバーヘッドだけでなく
書き換えたいなら内部可変性を持ちそのオーバーヘッドも加わるとともに
スタック上で済むときも必ずヒープ利用となるオーバーヘッドもある
817 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:49:12.36 ID:zzh5ASvo.net]: zennとかqiitaとかのrust記事みてると
活発に描いてた人は2019-2022くらいで
その後更新されてないのが多い
みんな試しただけで使ってないのか
818 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:51:48.91 ID:zzh5ASvo.net]: >>784
いくつものバージョンのrustやそのバージョン用のcratesを
それぞれ独立に管理して切り替えて使える統合環境なら嬉しいな
venvみたいな
819 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:54:10.60 ID:zzh5ASvo.net]: >>788
>Rustが良いのはムーブが基本なおかげで意図せぬメモリコピーが起きない

doubt
820 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:56:33.88 ID:zzh5ASvo.net]: >>790
特集のRustは知らんけど
特集じゃなかったときのインターフェースで紹介されたRustは
(インターフェース誌の読者に多いであろう)C言語利用者に判り易く説明されていた
そういうスタンスだからC知らん人にはきついのかも
821 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 08:58:41.51 ID:zzh5ASvo.net]: >>793
無くせない訳じゃなくて
参照カウンタを使わない描き方は今でも充分過ぎるほど可能
特に純粋な関数型言語を使ったことのある人は後者の方が得意だろう
822 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:03:05.94 ID:UG7jOJ2R.net]: ムーブは管理上の概念で、低レイヤではコピーしてる。
Rust のムーブはカスタマイズの余地なくコピーする (最適化で消えることはある) が C++ のムーブはカスタマイズの余地 (ムーブコンストラクタの定義) があるので効率の面から考えると Rust のほうがよいとは言えない。
823 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:29:23.45 ID:+smP1Ssu.net]: >>801
venvはないわー
cargoやrustupだけでずっと簡単に管理できる
IDEをそれらをGUIから活用するだけ
824 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:38:04.64 ID:4hBdJvP4.net]: コマンドプロンプトを無くせない理由を考え続けているそこのあなた
まあいいじゃんそういうの
825 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 09:38:06.14 ID:OKewYK0N.net]: >>800
当時記事書いてた一人だけど、日本語書籍も増えたしいまさら書くことないんだよね
アドベントカレンダーがあるならネタ考えるか、くらい
自分はまだRust使ってるし、当時記事書いてた人たちもRust使ってるベンチャーとかに転職してて、だいたいみんな書いてるんじゃないかな
826 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:09:47.61 ID:aKeOI53x.net]: Rustはカンファレンスとか見てても最近は成熟したからなのか特に目新しいものはない気がする
827 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:11:38.51 ID:CU8fyG8D.net]: vscodeにできてjetbrains製ideにできないことってある？
正直jetbrainsのヤツのほうがvscodeより使いやすい
828 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:27:13.13 ID:E2vTTaV1.net]: JetBrains製品は金払ってまで使うほどVSCodeより優れてるわけでないだけで良いIDEではある
VSCodeを何故使うかは商用利用無料だからに尽きるんだわ
829 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 10:59:18.93 ID:SqKWY/h6.net]: >>767 >>768
>traitが実装される具体的な型は全てsubtypeに相当する兄弟同士であるため
>supertrait/subtraitの場合に例えばある構造体についてそのインスタンスはどちらも同一になるから
どちらも同じ勘違いをしてるよ
よく読もうね

What is wanted here is something like the following substitution property:
If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T,
the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T
830 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:00:31.54 ID:l6/BNZgQ.net]: 仮にfleetが商用無料になるなら喜んでvscodeを捨てるけど金にがめついjetbrainsが商用無料で配るなんてありえない話
javaやkotlinならともかくrustなら商用無料のvscodeで十分
831 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:14:27.08 ID:3n/3tOrD.net]: >>812
そこでRustの場合はTがトレイトでSが構造体などの各型で
「impl T for S 」とS型にトレイトTを実装して
「let o1: S = ...」がS型の値(＝オブジェクト)になる
『object o1 of type S』　←存在する
『object o2 of type T』　←存在しない
したがってRustのトレイトはLSPとなんら関係がない
832 名前：デフォルトの名無しさん [2024/07/13(土) 11:36:15.00 ID:mV5TIlCk.net]: よく分からんけど
fn do_somethg(x: impl T)
にS型のオブジェクトoを渡すなら、do_somethingにとって o is T が成り立つんじゃない？
この関数は渡された o が S1 なのか S2 なのかは認識しないのだし
833 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:44:56.49 ID:4Ly9sDTU.net]: >>815
fn foo(x: impl T)は単相化されて
fn foo(x: S1)と
fn foo(x: S2)の二つの関数になるんだよ
いずれにしてもxはS1の値かS2の値であって
Tの値は存在しないね
834 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 11:50:56.55 ID:6r0IzkzM.net]: >>813
さすがフリーライダー。
相手に対する敬意が毛ほども無い。
835 名前：デフォルトの名無しさん [2024/07/13(土) 11:54:54.91 ID:mV5TIlCk.net]: それはコンパイルのされ方の話であって意味の上での問題ではない気がする
Box<dyn T> なら動的ディスパッチされるわけだし
let x: T = ... のような変数を作れないという意味ならその通りだけど、それはオブジェクト指向言語におけるインターフェースでも同じでは
(それともインターフェースに対してLSPは成り立たない？)
836 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:02:36.42 ID:7b/8td6H.net]: >>812,814,816
なんで毎回飛んでレスするの？
837 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:09:19.16 ID:Zf2Y/4l2.net]: 前も貼ったけどRustはこういうニーズを背負ってる

オブジェクト指向を学ばなかった話
https://qiita.com/adaiimps/items/e04ae03371435aeffe87

C++、ObjectiveC、JavaだったのがRust、LLVM、ELFになって、あーやっぱこっちの方が面白いねと、
好きも嫌いもなく色んな言語を学びまくってる人はLLVMは学ばないのかなと
838 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:15:08.95 ID:SXOx4oHh.net]: >>818
LSPでは「o1 of type S」と「o2 of type T」の二つのobjectの挙動を比較してるのよ
「o2」が存在しないと挙動の差を論じられないですよ
839 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:31:19.55 ID:IqeBToeS.net]: rust始めたけどtokioまわりの非同期処理が難しい…
840 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:34:40.11 ID:UG7jOJ2R.net]: 置換原則に沿うかどうかは具体的な実装を検証しないとわからないし、大抵の場合に機械的に検証することは出来ない。
型をサブタイプの関係にするのは原則に沿う「ことにする」という表明になることはあるが、原則に沿うことの保証にはならんのだ。
841 名前：デフォルトの名無しさん [2024/07/13(土) 12:40:54.94 ID:mV5TIlCk.net]: >>821
>>812 を字義通りに解釈するならそうだけど、その文章はC#やJavaが登場する前の1988年のもので、現在のオブジェクト指向にそのまま適用して良いのか？と思う
インターフェースでない、実体のあるクラスの継承関係についてしか言えなくなるし

現在だとリスコフの置換原則は抽象インターフェースも含んで説明される方が多いように思う
「クラスを継承する際のみに適用できるルール」のように説明されてるのは、少なくとも自分は見たことがない
842 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:44:05.69 ID:Bid5yHc7.net]: お前らずっと同じ話をループさせてんな😅
843 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 12:51:22.30 ID:kEBSnfkM.net]: >>824
親(基底)と子(派生)の挙動の差で満たすべき条件をLSPは挙げてるよね
少なくとも親にも挙動(実装)が存在しないとLSPを満たしているかどうか言及できないと思う
844 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 13:43:19.43 ID:4hBdJvP4.net]: >>825
好き嫌いの感覚に素直に従えば面白味のないループはすぐ止まりそうなのに
845 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 13:52:54.97 ID:E+PNnzD+.net]: PartialOrd: PartialEqは
PartialEq（等価判定）を持つ型にPartialOrd（半順序判定）を追加するときに
a.partial_cmp(b) == Some(Ordering::Equal)
と
a.eq(b) （⇔ a == b）
が同じになることを期待してる

この場合の置換の対象は型のインスタンスではなく使われる型の関数だから
LSPをインスタンスの置換に限定するか処理の置換にまで拡張するかで結論が変わる

PartialOrdの追加はPartialEqを使ってる既存のコードに影響しないから
技術的にはLSPと無関係ともいえるし
PartialOrdとPartialEqの等価判定の互換性は概念的にLSPの対象とも考えられる
846 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 14:35:50.27 ID:MYuplL5h.net]: つまりRustのトレイトは
LSPの原義に従うと対象外となり
拡張して考えるとLSPを常に満たす
ことになるわけか
847 名前：デフォルトの名無しさん [2024/07/13(土) 15:25:32.20 ID:mV5TIlCk.net]: >>829
意味の上で考えるとしても「常に」は満たさないかと

struct MyString(String);
impl Clone for MyString {
　fn clone(&self) -> Self {
　　Self("元の文字列と関係ない文字列".to_string())
　}
}

のようにすれば、そのトレイトが期待する動作に反した型は作れるわけで
引数や戻り値のシグニチャの同一性だけに注目するならtraitに違反することはできないけど、それなら継承やインタフェースでも同じで、「LSPに違反してはならない」という原則はそもそも意味がない (常に違反できないから) ってことになるし
848 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 15:38:58.70 ID:MYuplL5h.net]: >>830
それLSPのどの項目に違反してる？
LSPは振る舞いに関する形式的なものなのでそのような意味論にまでは踏み込んでいないよ
849 名前：デフォルトの名無しさん [2024/07/13(土) 15:50:29.46 ID:mV5TIlCk.net]: >>831
例えば
fn test_clone(x: impl Clone + PartialEq) {
　assert!(x.clone(), x);
}
はClone および PartialEq トレイトの振る舞いに依存したコードだけど、この振る舞いに反した型は作れるよね
トレイトは事後要件 (x.clone() == x) を定義できないし、そもそも Clone はそれを担保していないと主張することはできるけど、それならLPSって何のためにあるんだ？ってなるし
850 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 15:54:23.34 ID:4hBdJvP4.net]: 「内在論理」に踏み込めば争いを解決できる説のようなものか
逆効果なのでは？
851 名前：デフォルトの名無しさん [2024/07/13(土) 15:55:51.56 ID:mV5TIlCk.net]: 訂正
>>832 のアサート行は assert!(x.clone(), x) でなく assert!(x.clone() == x)
852 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 15:57:24.24 ID:UG7jOJ2R.net]: >>831
不変条件を弱められないルールだろう。
不変条件はシグネチャや定義域で表現できないものも含めた振る舞いの仕様全てのことで、挙動が (仕様に照らして) 望ましくなければ原則を満たさないと言える。
853 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 16:03:55.44 ID:E+PNnzD+.net]: 829でPartialEq/PartialOrdを例に出したのは
この２つのtraitがsuper/subの関係にあるからで
Cloneとその実装型の関係とは別だよ
PartialEqとPartialOrdの等価判定についてのLSPを考えてる

PartialOrd: PartialEqとする以上
PartialOrdの比較はPartialEqの等価条件を保存すべき←LSP?
みたいな
854 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 16:10:18.20 ID:MYuplL5h.net]: >>836
確かにそちらの例は二つのトレイトがsuperとsubの関係だからLSPを満たしてるけど
>>830の例はLSPとは関係ないな
855 名前：デフォルトの名無しさん [2024/07/13(土) 17:43:27.19 ID:mV5TIlCk.net]: >>831
意味でなく形式に拘るなら「事後要件を弱めてはいけない」などのルールは、要件がプログラム等の形式で表現されない限りLSPの評価の土台にすら上がらないってことにならない？

Cloneトレイトは公式のドキュメントに

// Required method
fn clone(&self) -> Self;
Returns a copy of the value.

とあって、exampleでは実際に assert_eq を使って説明しているので、この説明を元にCloneトレイトを実装する型の妥当性を判断して良いように思う
これでもまだ「それは意味論上のものでしかない」というなら、逆にそれをクリアしてクラス間の振る舞いを示している現実的な例を教えてくれ
856 名前：デフォルトの名無しさん mailto:sage [2024/07/13(土) 22:57:22.69 ID:ZTGyFNne.net]: >>838
それは単純な例だから上手くいってるように思い込めるんじゃないかな
例えばclassの場合はもっと複雑な例になってもsuperclassのコードと挙動が実際にあり
それとsubclassの挙動や(必要なら)コードと照らし合わせて判定できるよ

しかしtraitにはそれがないからドキュメントや付加assertなど一段上のメタ情報を用いなければ何も進めることができない
したがってLSPの枠組みと似てる面はあっても別物
857 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 04:00:15.58 ID:xmUtANA3.net]: 知らんけど
JavaとかC#の世界でも、interfaceが実装者に要求する条件を実装者が実際には満たさない、って場合にLSP違反って言われるの？
ならRustのtraitでも同じこと言ってよさそうだけど、多分言わんよな
858 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 05:23:41.72 ID:QaC7oPd0.net]: 継承なしのカプセル化だけなら普通のC言語でもできるし、再コンパイルの問題（変更を加えたファイルだけを再コンパイルすればいいという原則の破れ）も発生しない
それがそのままライブラリやオブジェクトの単位になったんじゃないの
859 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 06:49:30.82 ID:ma8dE8UE.net]: 文系：xとは未知のもの
厨房：いや未知のものはyやろ
理系：未知のものはfですdf/dx=g(f)を解きます
860 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:37:29.94 ID:iqWqiKXK.net]: >>841
Rustのtraitにはクラスのような継承はないけど、抽象的なコードを継承できるよ
861 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:37:59.13 ID:iqWqiKXK.net]: 例えばIteratorのtraitにはこのようにfoldメソッドのコードがあって

fn fold<B, F>(mut self, init: B, mut f: F) -> B
where
　Self: Sized,
　F: FnMut(B, Self::Item) -> B,
{
　let mut accum = init;
　while let Some(x) = self.next() {
　　accum = f(accum, x);
　}
　accum
}
862 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:39:51.02 ID:iqWqiKXK.net]: 未知のIteratorであっても重複コードを書くことなく自動的にこのfoldメソッドが使える
863 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 07:40:10.97 ID:iqWqiKXK.net]: クラスのメソッド継承との決定的な違いは、このコードにメンバー変数は一切登場せず、つまりいかなる構成の型からも独立した抽象的なコードであること
864 名前：デフォルトの名無しさん [2024/07/14(日) 09:23:36.10 ID:JssLuzWj.net]: fold って next とどうちがうん
865 名前：デフォルトの名無しさん [2024/07/14(日) 10:13:20.02 ID:aq5pPuoi.net]: >>847
nextはイテレーターを一つ進めるもの、foldやreduceはイテレーターに対して畳み込みを行うもの
例えば「配列内の全ての数値を足し合わせる」とか「全ての数値を掛け算する」「配列内の文字列を全て連結する」いった操作を行うものだよ

この類のものは他の言語でも使われるし、簡潔なコードを書けるようになるから知っておくと良いよ
配列等のコンテナに対して一般に map, filter, reduce と呼ばれる操作があって、そのうちreduceは「要素を畳み込んで1つの値にする」もの
畳み込む方法を関数で渡すもので、概念的には [1, 2, 3].reduce(add) や [1, 2, 3].reduce(multiply) のような形になる
渡す関数は関数のほかクロージャ (言語によってはラムダ式とも) も使える
こんな感じに抽象化するとfor文を使わなくて済むし、何をやってるかが明確になる
866 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 10:32:15.39 ID:iqWqiKXK.net]: 言語によって呼び名や使い分けが微妙に異なるけど
Rustでは2種類をこう呼び分けています
foldは初期値を別途指定する万能型の畳み込み
reduceは初期値が最初の要素となる畳み込み
867 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 10:33:24.33 ID:iqWqiKXK.net]: そして万能型のfoldを呼び出す形で
このような特定の型の構造に依存しない抽象的なコードが
trait Iteratorに用意されているため使えます

fn reduce<F>(mut self, f: F) -> Option<Self::Item>
where
　Self: Sized,
　F: FnMut(Self::Item, Self::Item) -> Self::Item,
{
　let first = self.next()?;
　Some(self.fold(first, f))
}
868 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 11:05:51.89 ID:iqWqiKXK.net]: なぜ二種類あるのか？と
869 名前：いうと 長さ0だと最初の要素すらないため reduceはOption型が返る特徴があります 例えば和を求める場合でも 長さ0だったらNoneになってほしいならば reduce(|sum, n: i32| sum + n) 長さ0なら和が0となってほしいならば fold(0, |sum, n: i32| sum + n) と使い分けることができます ちなみに後者はsum()メソッドが用意されています []: [ここ壊れてます]
870 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 11:33:51.37 ID:iqWqiKXK.net]: ごめんなさい
>>851で型指定「: i32」の部分は不要です
Iteratorの要素の型に必ず定まります
空配列[]から始めると型指定がどこにもないため横着してそこで指定しちゃったという顛末でした
871 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 12:47:51.97 ID:JssLuzWj.net]: >>822
tokio 自体は難しくないけど
cargo test と組み合わせると難しくなる罠
872 名前：デフォルトの名無しさん [2024/07/14(日) 12:50:40.22 ID:JssLuzWj.net]: >>848
map も reduce も filter も知ってるけど(pythonとかから)
fold は知らんかった?楠
873 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 12:54:55.73 ID:JssLuzWj.net]: >>850
python の reduce は初期値を [0] にするのも任意に設定するのも
同じ reduce という名前でいけるのが
Rust だと reduce と fold で使い分ける必要があるということね
Rust が面倒だと言うことは理解した
874 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 13:21:58.79 ID:iqWqiKXK.net]: >>855
そういうことではないよ
RustではOption型やResult型でエラーや異常値を含めて正しい状況を値として得られるんだよ
例えば長さ0で初期値なしの時に
Pythonだとエラーだよね
Rustは常に値として返してくれて今回はOption<Self::Item>型
875 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 14:06:11.77 ID:CpW1/GRz.net]: >>854
ML 系とか LISP 系の言語ではだいたい reduce や fold は用意されてるね。
ものによっては右側 (シーケンスの終端) から畳み込むとかのバリエーションもある。
876 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 14:15:44.82 ID:iqWqiKXK.net]: Rustならrev().fold(...)だね
877 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 15:28:53.80 ID:QaC7oPd0.net]: テンプレートが出てきたあたりからC++の勉強をやめたのだけど
これは「型を引数に取ってインスタンス化する」ということでおｋ？
それがトレイトをまたいだ場合、いつどこで誰が何してるか分からなくなる
ファイルをまたぐインライン関数みたいにソースレベルでなされること？
878 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 16:59:00.63 ID:Q38o8Kq2.net]: >>840
JavaとかC#の世界でも、interfaceが実装者に要求する条件を実装者が実際には満たさない、って場合にLSP違反って言われるの？
言われるよ
リスコフ本人が書いたJavaの本にも書いてある
879 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 17:32:49.60 ID:Q38o8Kq2.net]: >>839
>ドキュメントや付加assertなど一段上のメタ情報を用いなければ何も進めることができない
一段上のメタ情報であるspecificaitonを使いなさいというのがリスコフの教え
それがBehavioral SubtypingってものでLSPが伝えようとしてる原則だよ
880 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 20:15:07.35 ID:QaC7oPd0.net]: ああ、なんだ
クレート＝ELFファイルだと思ってたけど違うのね
881 名前：デフォルトの名無しさん mailto:sage [2024/07/14(日) 23:33:04.31 ID:jL63bGYb.net]: もちろんクレートはコンパイルしてELFに出来得る
882 名前： 警備員[Lv.12] mailto:sage釣 [2024/07/15(月) 00:49:06.25 ID:iuOQZB5q.net]: そうかCOFFあかんか。
AIXとかはどうするんだろう？
883 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 01:06:24.34 ID:qZQFNGwo.net]: LLVMのバックエンドにCOFFもあるよ
884 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 01:09:28.33 ID:RXziJOxB.net]: LLVMの役割
ELFもCOFFもXCOFFもいける
885 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 01:55:53.37 ID:S6UfnUI4.net]: >>860-861
なるほどね、本当に特定の言語処理系の型システムの実装が云々というところからは離れたところにある概念なんだ
あえて関連付けるなら、型システムの部分型付け関係がbehavioral subtypingにもなるように定義すべきであると
上位型が具体型であるために暗黙の条件が多数想定される状況では特にLSPを意識すべきだが、それに限定される概念ではないと
886 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 02:35:13.63 ID:fmM+TfOR.net]: supertypeの実装がない場合は
LSPの不変条件・事前条件・事後条件などsubtypeの実装と比較しようがなく
LSPの対象になりようがないよね
887 名前：デフォルトの名無しさん [2024/07/15(月) 03:42:20.85 ID:csp8v2ux.net]: docs.rs の左上のRマーク
今話題のRen4のマークに似てるね
888 名前：デフォルトの名無しさん [2024/07/15(月) 09:46:03.12 ID:kpV4D65H.net]: コレクションしないんだから狭義には参照カウンタはGCとは言えない。
広義には含めてやってもいいが。
889 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 11:20:28.28 ID:qZQFNGwo.net]: ライブラリは.rlibまたは.rmetaで、これもELFやCOFFとは別物
ふむ
890 名前： 警備員[Lv.1][新芽] [2024/07/15(月) 11:29:04.89 ID:omk2e105.net]: たしかにRマークってRustから周りのやつ外したような感じじゃん
891 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 11:58:24.83 ID:K85WsTqt.net]: Ren4のRマークはsans-serifのゴシック体だからRustのロゴとは全然違うだろ
本人のやる気、こだわりのなさをフォントで表現してるんだから
RustのRと一緒にしたら双方に失礼
892 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 13:14:40.10 ID:ZO/EZAih.net]: 単に好みの問題だけど
ウィルスっぽくて気持ち悪い
好きじゃない
893 名前：デフォルトの名無しさん [2024/07/15(月) 14:14:44.43 ID:ko+PCaVU.net]: >>874
元々サビ菌がモチーフやからしゃーない
894 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 18:49:44.14 ID:GgRIn2WF.net]: 独裁者にも見た目がダサい奴がよくいるけど言っても無駄だ
デザインの力とは全然違う別の力でねじ伏せてくる
895 名前：デフォルトの名無しさん [2024/07/15(月) 19:16:07.61 ID:Vjas5sQD.net]: ダサいという指摘に理由を説明しても、ダサいことは変わらないんだよな
言語がダサければ信者もダサい
うだうだ言いながらダサい服着てそう
896 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 22:03:42.65 ID:e+J3OGv0.net]: イテレータ要素をヒープに格納するにはこれでいいんか
.fold(Vec::new(), |mut v, t| { v.push(t); v })
897 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 22:12:32.29 ID:S6UfnUI4.net]: またイテレータの話してる
898 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 22:50:12.36 ID:9YaXaz6n.net]: >>878
collectしろや
899 名前：デフォルトの名無しさん [2024/07/15(月) 23:25:29.58 ID:wT4qVw/w.net]: >>878
分かって書いてるかもだけど一応
let v = (0..10).collect::<Vec<i32>>();
コンテナにまとめるならこんな感じに collect を使う
例えば文字を走査するイテレーターをStringにcollectするようなことも可

型パラメーターは推論が効くのでそれに任せても良い
左辺に情報があるならcollectの型パラメーターはいらない
let v: Vec<i32> = (0..10).collect();
要素の型が分かるなら、右辺のコンテナの中身は_で推論させても良い
let v = (0i32..10).collect::<Vec<_>>();
900 名前：デフォルトの名無しさん mailto:sage [2024/07/15(月) 23:35:20.09 ID:nug4GWMJ.net]: クロージャにキャプチャさせれば既存ベクタへ格納も追加もできる
let mut v = Vec::new();
iter.fold((), |_, t| v.push(t));
しかしこれではfold使ってる意味がなくこれと一緒　
iter.for_each(|t| v.push(t));

もちろん正解は既存Vecへ追加なら
v.extend(iter);
新規にVecへ収集なら
let v = iter.collect::<Vec<_>>();
901 名前：デフォルトの名無しさん mailto:sage [2024/07/16(火) 23:25:36.51 ID:ab19AXDr.net]: Foo::from_iter(iter)でもいいね
例えばVec::from_iter(iter)
特にIntoIteratorな時にinto_iter()を省けて見やすいよ
902 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 18:51:22.39 ID:Hw1cPZyQ.net]: イテレータをcollectしたい場合と
イテレータではないIntoIteratorを別の構造体に変換したい場合とは文脈が違うでしょ

from_iterを直接呼ぶのは基本的に後者
前者の場合にターボフィッシュ書かなくてもいいという理由で
from_iterを直接呼ぶのはidiomaticではない
903 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 21:48:43.22 ID:3eay5eeN.net]: 前者のケースでfrom_iterを直接呼んでても分かるから別にいいよ
自分で書くときはcollect使うけど
904 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 23:54:54.61 ID:zgRAxdKk.net]: これは短い方がいい
let x = HashMap::<_, _>::from_iter(vec);
let x = vec.into_iter().collect::<HashMap::<_, _>>();
905 名前：デフォルトの名無しさん mailto:sage [2024/07/17(水) 23:55:29.92 ID:zgRAxdKk.net]: これはほぼ長さ変わらないからどちらがわかりやすいか
let x = HashMap::<_, _>::from_iter(iter);
let x = iter.collect::<HashMap::<_, _>>();
906 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 01:10:31.87 ID:CNIyJc+8.net]: どちらも一度変数で受ける形になるので型アノテーションが必要なら
let x: HashMap<_, _> のように基本的には左辺に書く

HashMapなら型パラメータ部分も推論に頼らず
明示的に書くことのほうが多いかもしれない

イテレータをcollectしたい場合というのは
イテレータのメソッドチェーンで各種処理をしてから
最終的にcollectする形になることが多いから
from_iterの直呼びじゃなくcollectが好まれる
907 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 02:40:28.19 ID:0QBRSK+b.net]: ところでchronoって、しょっちゅうAPIが変わるし
やたら冗長な書き方になるし結構クソじゃない？
908 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 12:05:40.95 ID:WL/aeG4d.net]: 書き方が気に入らないならtime-rsを試してみたら？
909 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 21:07:48.37 ID:2m7Ost/Q.net]: なるほど

trait Iterator {
　type Item;
　
　fn collect<B: FromIterator<Self::Item>>(self) -> B
　where
　　Self: Sized,
　{
　　FromIterator::from_iter(self)
　}
}
910 名前：デフォルトの名無しさん mailto:sage [2024/07/18(木) 23:31:33.62 ID:GQ1B8wHA.net]: 代数的データ型ってなんかすごいけど知名度がモナドより低いな
911 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 02:03:52.09 ID:MUvBupZH.net]: >>890
使ってみたけど、time-rsいいね
いつのまにかダウンロード数でchronoを上回る競合があったとは知らんかった
タイムゾーンの扱いがやや簡略化されてるけど、夏時間のない日本人的には問題ない
月を直接intで指定できないのが英語仕様やな……ってちょっと気になる
912 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 03:51:08.70 ID:riLGg6QV.net]: >>891
この各収納先への移譲と両側のトレイト境界が汎用化の肝
trait FromIterator<A>: Sized {
　fn from_iter<T: IntoIterator<Item = A>>(iter: T) -> Self;
}
913 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 06:06:24.35 ID:LryDU6eW.net]: Rustはジェネリックとトレイト境界と抽象的なデフォルト実装のおかげで
安全で利便性の高いコードの汎用共通化に成功していますね
914 名前：デフォルトの名無しさん [2024/07/19(金) 23:21:36.34 ID:rC6z5NUh.net]: cloud strike のはテロルやね
915 名前：デフォルトの名無しさん [2024/07/19(金) 23:30:11.35 ID:rC6z5NUh.net]: >>886
let x; HashMap::<_, _> = vec.try_into()?;

>>889
＋１
916 名前：デフォルトの名無しさん mailto:sage [2024/07/19(金) 23:52:20.75 ID:8WlCJE3Q.net]: >>897
エラーとなりますた
917 名前：デフォルトの名無しさん mailto:sage [2024/07/20(土) 00:12:48.41 ID:bNknJoN/.net]: >>896
ウィルスバスター以来の快挙やね
918 名前：デフォルトの名無しさん mailto:sage [2024/07/20(土) 14:16:49.05 ID:F167yFzL.net]: >>898
; が : の間違いかな

>>899
暴落予想
note.com/asset_n_ichi/n/nceaa6f318b1e
919 名前：デフォルトの名無しさん mailto:sage [2024/07/20(土) 23:38:20.92 ID:6EAP68vq.net]: >>897
HashMapとVecにTryFromが実装されていないから無理
FromIteratorが実装されているのでそれを使う
920 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 01:48:23.56 ID:eUhj6//q.net]: ★┷┓
┃D┃
┃D┃
┃K┃
┃で┃
┃も┃
┃r┃
┃u┃
┃s┃
┃t┃
┃が┃
┃使┃
┃え┃
┃ま┃
┃す┃
┃よ┃
┃う┃
┃に┃
┗━★
921 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 09:43:03.00 ID:QhoywuRk.net]: >>901
こういうのが「Rustは学習コストが高い」って言われる原因なんだろうな
答えを知ってる人は判ってても答えを知らない人は判らない
答えを調べるのにコストがかかりすぎる
922 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 10:14:17.60 ID:TGGT0XLq.net]: とあるライブラリに変な癖があるという話は
どの言語でもあるからそういう話ではないだろ
923 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 10:29:10.85 ID:U3c7smqS.net]: イテレータ使ったことない
924 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 10:35:28.58 ID:W0nR4Dwz.net]: >>903
Rustはその点シンプルでクセもなく覚えやすい

基本的に複数の要素ならFromIterator
VecでもHashMapでも何でもいける
複数のcharやstrなどからString作成もいける
複数のstrやStringやPathなどからPathBuf作成もいける

Fromは基本的に単独要素や配列(＝静的固定長)から他へ変換
925 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 11:03:59.33 ID:BMrg5vDt.net]: >>903
>>897のはコンパイルエラーの内容が読めればすぐわかる
エラーの内容が読める程度の基礎力は最初に勉強して身につける必要がある
そもそもtry_intoでどういうケースならエラーにして欲しいのか考えればおかしいことに気付く

サードパーティライブラリの学習コストは他の言語に比べると顕著に高いが
基本的な言語機能や標準ライブラリは言うほど高くない
JavaやC#あたりと比べるとむしろ学習コスト低いんじゃないかと思う
926 名前：デフォルトの名無しさん [2024/07/21(日) 11:04:04.35 ID:xuKRyHnL.net]: >>903
それくらいchatGPTで教えてもらえるだろ
927 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 11:14:46.17 ID:BMrg5vDt.net]: >>908
俺もそう思って試してみたけど駄目だね
エラーの簡単な原因とcollect使えみたいな代替案は出してくるけど
根本的な理解につながる答えを返せないだけでなくいろいろと間違った情報を返してくる
928 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 11:48:09.12 ID:W0nR4Dwz.net]: from_iter(array)で済むのに
なぜ配列からHashMapへのFromがあるのか理由はおそらく
配列からmoveするinto_iter()が数年前までなかったためだと思う
今は配列を含めて要素が複数なら→イテレータ利用→FromIteratorと覚えればよいかと
929 名前：デフォルトの名無しさん [2024/07/21(日) 11:54:05.33 ID:9I2odrUJ.net]: そもそもイテレーターとコンテナの概念を勘違いしてる可能性ありそう
別種のコンテナ同士の変換は (特別な対応がない限り) 直接的には無理で、イテレーターを介して中身の要素を走査すれば渡せるということ

みかん箱を冷蔵庫に変換することはできないけど、箱の中のみかんを1つずつ取り出して、それを冷蔵庫型に纏める (collect) ことはできるような感じ
930 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:08:53.38 ID:QhoywuRk.net]: 今回は >>910 さんをベストアンサーとさせて頂きます
みなさんご協力ありがとうございました
931 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:17:32.86 ID:rbHgMj6q.net]: >>911
それは単に抽象度の違いであって勘違いでも何でもない
932 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:17:32.92 ID:QhoywuRk.net]: >>911
勘違いはしてない

use std::collections::HashMap;
use std::iter::FromIterator;

fn main() {
let u = vec![("hoge", 1), ("fuga", 2)];
let x: HashMap::<_, _> = u.into_iter().collect();
println!("{:?}", x);
let v = vec![("hoge", 1), ("fuga", 2)];
let y = HashMap::<_, _>::from_iter(v); // use std::iter::FromIterator
println!("{:?}", y);
let w = [("hoge", 1), ("fuga", 2)]; // array
let z = HashMap::<_, _>::from(w);
println!("{:?}", z);
}
933 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:21:47.94 ID:QhoywuRk.net]: なぜ Vec から HashMap は from が使えないのか？
の問いに GPT は答えてくれない
934 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:29:53.31 ID:+gih9iRs.net]: >>910
順番が逆
arrayにIntoIteratorが実装された方が先で
From array for HashMapのほうが後
935 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 12:32:17.29 ID:BMrg5vDt.net]: >>915
そこはFromのimplがないからと答えてくれる
coherenceの制約を先回りして答えてくれるかどうかは質問次第
936 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 13:57:28.77 ID:W0nR4Dwz.net]: >>916
ありがと
調べたらその順だね
そうなるとFrom<配列>だけを特別に用意した理由は配列が基本型だからだろうか
HashMap::from(array)のコードを見ると
HashMap::from_iter(array)とFromIteratorの実装を呼び出すだけなので
937 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:06:46.61 ID:nMuf3u03.net]: MapやSetのリテラルがないけどリテラルに近い感覚で初期化したい場合の代替策として用意されたのがFromの実装
938 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:20:17.13 ID:BJsLblxy.net]: _iterの5文字が節約できるメリットだけか
939 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:39:36.83 ID:u5tRysNp.net]: >>920
タイプアノテーションの要不要があるのでもっと節約できるよ
940 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 16:43:19.24 ID:BJsLblxy.net]: >>921
不要になる例を出して
941 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 17:05:45.63 ID:QAZ3DYjh.net]: FromがあるとIntoが使えるからHashMap返すときとか引数で渡すときに
HashMap::from([..])
の代わりに
[..].into()
で書ける

型を明記するletだと大差ないかも
let map: HashMap<K, V> = [..].into();
let map = HashMap::<K, V>::from([..]);
942 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 17:22:33.98 ID:BJsLblxy.net]: >>923
そこでタイプアノテーションが不要になる例はないよな
関数の引数型か返り型に書いている

into()と書ける件も
collect()と書けるから
FromIteratorに対してFromもあるメリットは3文字節約できるだけか
943 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 21:02:32.72 ID:eUhj6//q.net]: dyn traits以外にinto使うなよ。変換するんだから

let s = "Hello, world!";
let string = Into::<String>::into(s);

じゃなくて

let s = "Hello, world!";
let string = String::form(s);

だろ。
944 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 21:07:32.49 ID:BUmQiTHC.net]: は？
945 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 22:10:59.79 ID:kEjkNYpd.net]: >>922
use std::collections::HashMap;

fn main() {
let xs = [(1, "a"), (2, "b"), (3, "c")];
let map = HashMap::from(xs);
println!("{:?}", map);
}
946 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 22:23:54.17 ID:vNf5wQaP.net]: >>927
HashMap::from_iter(xs)で十分じゃね
947 名前：デフォルトの名無しさん mailto:sage [2024/07/21(日) 22:30:45.10 ID:kEjkNYpd.net]: >>928
error[E0283]: type annotations needed for `HashMap<i32, &str, _>`
--> src/main.rs:5:9
|
5 | let map = HashMap::from_iter(xs);
| ^^^ ------- type must be known at this point
|
948 名前：デフォルトの名無しさん mailto:sage [2024/07/22(月) 12:16:14.88 ID:7a9cZObY.net]: 配列からのFromは機能が制限されている
struct HashMap<K, V, S = RandomState> { ... }
impl<K: Eq + Hash, V, S: BuildHasher + Default> FromIterator<(K, V)> for HashMap<K, V, S> { ... }
impl<K: Eq + Hash, V, const N: usize> From<[(K, V); N]> for HashMap<K, V, RandomState> { ... }
949 名前：デフォルトの名無しさん mailto:sage [2024/07/22(月) 12:18:01.98 ID:7a9cZObY.net]: つまりFromは重いデフォルトハッシャーに固定されてしまっている
FromIteratorを使えば自由に速いものを利用できる
let xxx = HashMap::<_, _, FxHash>::from_iter(array);
950 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 01:07:15.84 ID:XvQFw5Nb.net]: HashMap::from(配列)の場合は
デフォルトハッシャーで困るユースケースは稀だから
APIのエルゴノミクスのために意図的にRandomStateに固定してる
そのおかけでタイプアノテーションなしで書ける

タイプアノテーション無しの場合はデフォルト指定の型を優先的に使うよう
Rustのコンパイラが改良されればこの辺の差はなくなる
951 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 01:10:26.97 ID:XvQFw5Nb.net]: >>931
>let xxx = HashMap::<_, _, FxHash>::from_iter(array);
FxHashのところはFxBuildHasherだね
let xxx = FxHashMap::from_iter(array);と書いたほうがいろいろ親切

親切設計のライブラリなら
let xxx = AHashMap::from(array);
のようにFromIteratorだけでなくFromも使える
952 名前：デフォルトの名無しさん [2024/07/23(火) 01:31:49.01 ID:Rfg4Mjqa.net]: tupleをiteratorしたいんだが無理？
953 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 02:50:50.92 ID:l+hNtTPE.net]: こういう意味？
let t = ("abcde", "fghijkl", "mno", "pqrstuvw", "xyz");
assert_eq!("abcdefghijklmnopqrstuvwxyz", Into::<[_; 5]>::into(t).into_iter().collect::<String>());
954 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 09:22:40.63 ID:iSDzXJU2.net]: 同じ型だけの要素で構成されるtupleならいけそうだけど
色んな型ば混ざってるtupleはエラー出そう
955 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 11:25:10.18 ID:ijWLrFq+.net]: dynにすれば色んな型を混ぜられる
関数から返すときはBox<dyn ...>にする
例えば数値と文字列が混じる有名な例をRustでdynを使って書くと

type FizzBuzz = Box<dyn std::fmt::Display>;

fn fizz_buzz_iter() -> impl Iterator<Item=FizzBuzz> {
　(1..).map(|int| match (int % 3, int % 5) {
　　(0, 0) => Box::new("FizzBuzz") as FizzBuzz,
　　(0, _) => Box::new("Fizz"),
　　(_, 0) => Box::new("Buzz"),
　　(_, _) => Box::new(int),
　})
}

fn main() {
　for x in fizz_buzz_iter().take(30) {
　　println!("{x}");
　}
}
956 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 17:24:06.93 ID:hqmWVJB3.net]: またFizzBuzzイテレータ書いてる……
957 名前：デフォルトの名無しさん [2024/07/23(火) 21:36:57.26 ID:1jhTJKzb.net]: >>936
Haskellだとタプルって構造体代わりだから、色んな型が混ざってる方が普通だけど…。
（ともすれば関数も入れるし。同じ型だけってのはリストのイメージ）

Rustじゃ用途違うん？
958 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 21:58:12.50 ID:joaeWjir.net]: タプルは型の制限なくバラバラでいいよ
今回はそれを>>934「iteratorしたい」なので
同じ型に揃えるためにdynかenumを使う
959 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:07:54.81 ID:tKFzmUCx.net]: ほとんどの言語でオブジェクトを返す時にヒープを使うから
RustでもBox<dyn>を使っても構わないけど
ライフタイムさえ満たしてやればヒープを使わずに&dynにできるよ

use std::fmt::Display;
type FizzBuzz<'a> = &'a dyn Display;

fn fizz_buzz_iter<'a, T: Display>(i: &'a[T], s: &'a[&str; 3]) -> impl Iterator<Item = FizzBuzz<'a>> {
　(1..).map_while(|int| match (int % 3, int % 5) {
　　(0, 0) => Some(&s[0] as FizzBuzz),
　　(0, _) => Some(&s[1]),
　　(_, 0) => Some(&s[2]),
　　(_, _) => i.get(int).map(|int| int as FizzBuzz),
　})
}

fn main() {
　let i: [_; 256] = std::array::from_fn(|i| i as u8);
　let s: [_; 3] = ["FizzBuzz", "Fizz", "Buzz"];
　for x in fizz_buzz_iter(&i, &s).take(30) {
　　println!("{x}");
　}
}
960 名前：デフォルトの名無しさん [2024/07/23(火) 23:38:39.26 ID:QoNSkCmh.net]: 「tupleでイテレートできないの？」という質問に「こういうイテレータなら異なる型を混ぜられるよ」と回答するあたりがいかにもな感じ
率直に「できる/できない」で回答した上で補足として書けばいいのに
961 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:40:03.74 ID:38zrS1+w.net]: トレイトオブジェクトをdynと呼ぶのは複オジだけ
962 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:40:30.32 ID:38zrS1+w.net]: >>942
それな
963 名前：デフォルトの名無しさん mailto:sage [2024/07/23(火) 23:49:18.56 ID:lLea54if.net]: Rust 2018 editionからdyn必須に変わった
964 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 00:02:23.05 ID:QMkBbV1F.net]: できる/できないで言えばできるよ

タプルの要素がすべて同じ型で要素数が12個以内ならFrom/Intoで配列に変換してイテレートする
それ以外ならextension traitで自前のイテレータを返すメソッドをタプルに実装する
他にも方法あるけどこの2つが主

タプルの型・要素数、イテレート時の型を汎用化したい場合はマクロが必須でそこそこめんどくさい
特にヘテロなタプルを汎用的にイテレート用の型に揃えるのはめんどくさい

本当にタプルで管理するのが望ましいのか
タプルで管理しつつイテレータで回すのがベストなのか
まずはよく考えたほうがいいと思う
965 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 00:15:33.28 ID:sAqPevwn.net]: dynを使えば型が何種類でもいけてトレイト境界も使えて楽だろうけどdynは重い
Fizz Buzzのように2種類の型で済むならEitherを使う
色んなトレイトを透過的に対応してくれている

use either::Either::{self, Left, Right};

type FizzBuzz = Either<usize, &'static str>;

fn fizz_buzz_iter() -> impl Iterator<Item = FizzBuzz> {
　(1..).map(|int| match (int % 3, int % 5) {
　　(0, 0) => Right("FizzBuzz"),
　　(0, _) => Right("Fizz"),
　　(_, 0) => Right("Buzz"),
　　(_, _) => Left(int),
　})
}
966 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 00:35:21.34 ID:UKniupNy.net]: リフレクションのサポートとかにもっと力入れてれば普通にできるんだろうけど、しゃあなし
Rustはそういうの好かない言語だから
967 名前： 警備員[Lv.2][新芽] mailto:sage [2024/07/24(水) 00:44:54.58 ID:djH/Nw1D.net]: rustって流行るかな
968 名前：デフォルトの名無しさん [2024/07/24(水) 03:12:39.74 ID:s3z853Sv.net]: >>940
タプルをイテレーションしたい…。

リストとか、配列みたいに使いってことですよね？
Haskellでは無理ですが、Rustでは可能なのでしょうか？
（構造体代わりと言った通り、構造体をイテレーションしようと思わないですよね？）

Python,RubyのリストとHaskellのそれみたいに、そもそもの意味が違う可能性もありますし…。
969 名前：デフォルトの名無しさん [2024/07/24(水) 03:25:04.27 ID:sCVmnNU/.net]: >>935
let t = ("abcde", 123, "mno", "pqrstuvw", 456);
for e Into::<[_; 5]>::into(t).into_iter() {
println!("{:?}", e)
}
無理ポorz
970 名前：デフォルトの名無しさん [2024/07/24(水) 03:30:03.16 ID:sCVmnNU/.net]: >>946
それっぽいクレートがあるけどよう判らん
これはどんな感じ？
https://crates.io/crates/tuple-iter
971 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 03:57:10.87 ID:yTLgnmif.net]: これは典型的なXY問題だから相手にするだけ無駄
質問者は本当に解決したい元の課題Xを素直に話すべき
自分の思い込みで勝手に判断して進めた二次的な課題Yについて質問しているからそれについては相手にしなくていい
972 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 04:42:12.08 ID:sCVmnNU/.net]: >>946
imple IntoIterator for (&str, u64, &str, &str, u64) {
...
}
で出来るかと思ったけど
this is not defined in the current crate because tuples are always foreign
973 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 05:38:42.31 ID:U0F2g2Py.net]: dynやenumにしろと本質的なアドバイスをもらえているのに対応しようとしない人
974 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 07:25:15.81 ID:Py4dd1Kh.net]: たしかにXY問題だな
「異なる型が入り乱れてイテレートしたい」←何のために？
「異なる型が入り乱れてタプルがある」←どうやってそれが出来た？
975 名前：デフォルトの名無しさん [2024/07/24(水) 08:43:52.20 ID:NUYI7xpt.net]: ・タプルは型を混合できる
・タプルはイテレートできない
・異なる型でのイテレートがしたいなら、タプルの代わりに Box<dyn Trait> のような動的型かenum (直和型) の配列を使う
で良いんじゃない？
976 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 08:43:57.79 ID:sCVmnNU/.net]: とりあえず出来ました
struct Hoge<'a> { t: (&str, u64, &str, &str, u64) }

impl<'a> IntoIterator for Hoge<'a> {
type Item = Fuga<'a>;
type IntoIter = std::vec::IntoIter<Self::Item>;

fn into_iter(self) -> Self::IntoIter {
vec![
Fuga::from(self.t.0),
Fuga::from(self.t.1),
Fuga::from(self.t.2),
Fuga::from(self.t.3),
Fuga::from(self.t.4),
].into_iter()
}
}
みなさんありがとうございました
977 名前：デフォルトの名無しさん [2024/07/24(水) 08:50:34.05 ID:NUYI7xpt.net]: XY問題だとか言うけど、上のFizzBuzイテレーターなんかはXとYのどちらとも関係ないでしょ
既にあるデータに対してイテレートする方法でなく、FizzBuzを0から生成するだけだから
それをしつこく何度も書くあたりが本物
978 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 09:24:46.95 ID:eaHzhPzb.net]: >>959
それな
979 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 09:30:08.78 ID:+W2StRcH.net]: 意味のないFizzBuzzを散々書いておいて答えられなくなったら急に質問者を攻撃する複オジくん草
980 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:35:19.94 ID:qFVR7Ywl.net]: 必要な個数のタプルを配列に変換するコードでいいんじゃないかな
これは長さ自由に機械的にマクロで生成できそう

struct Wrapper<A, B, C, D, E>((A, B, C, D, E));

impl<A, B, C, D, E> From<Wrapper<A, B, C, D, E>> for [Tx; 5]
where
　Tx: From<A> + From<B> + From<C> + From<D> + From<E>,
{
　fn from(x: Wrapper<A, B, C, D, E>) -> Self {
　　[Tx::from(x.0.0), Tx::from(x.0.1), Tx::from(x.0.2), Tx::from(x.0.3), Tx::from(x.0.4)]
　}
}

impl<A, B, C, D, E> IntoIterator for Wrapper<A, B, C, D, E>
where
　Tx: From<A> + From<B> + From<C> + From<D> + From<E>,
{
　type Item = Tx;
　type IntoIter = std::array::IntoIter<Self::Item, 5>;
　
　fn into_iter(self) -> Self::IntoIter {
　　let x: [Self::Item; 5] = self.into();
　　x.into_iter
981 名前：() } } []: [ここ壊れてます]
982 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:36:33.67 ID:qFVR7Ywl.net]: あとはタプルに登場する型を列挙して
例えばこんなコードを機械的に自動生成させてしまえばいいね

type T1 = &'static str;
type T2 = i64;
type T3 = f64;

enum Tx { T1(T1), T2(T2), T3(T3), }

impl From<T1> for Tx { fn from(x: T1) -> Self { Self::T1(x) } }
impl From<T2> for Tx { fn from(x: T2) -> Self { Self::T2(x) } }
impl From<T3> for Tx { fn from(x: T3) -> Self { Self::T3(x) } }

impl std::fmt::Display for Tx {
　fn fmt(&self, f: &mut std::fmt::Formatter) -> std::fmt::Result {
　　match self {
　　　Self::T1(x) => write!(f, "{x}"),
　　　Self::T2(x) => write!(f, "{x}"),
　　　Self::T3(x) => write!(f, "{x}"),
　　}
　}
}
983 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:38:12.03 ID:qFVR7Ywl.net]: そうするとタプルの中の型の順番は任意でよくて
タプルをラッパーにかませるだけで利用できるよ

fn main() {
　let tuple = ("abcde", 123, "nop", 0.456, 789);
　for x in Wrapper(tuple) {
　　println!("{x}");
　}
　for (i, x) in Wrapper((-1, "pi", 3, 3.14159, "END")).into_iter().enumerate() {
　　println!("{i}: {x}");
　}
}
984 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:43:52.56 ID:mjGiit/q.net]: 効いてる効いてるw
985 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 12:49:36.37 ID:TJmYfYAi.net]: 「XY問題だから相手にするだけ無駄」と言い放っておいてからの～～
986 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 17:04:11.48 ID:1Kw3Uuff.net]: もっと建設的な話題はないの？
987 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 19:14:00.84 ID:UKniupNy.net]: 5chより建設的なコミュニティを列挙し移住を検討するのが目下最も建設的な話題である
988 名前：デフォルトの名無しさん [2024/07/24(水) 21:00:33.77 ID:bzm5y73f.net]: 最近出た便利クレートの話とかすれば良いんじゃね？
989 名前：デフォルトの名無しさん mailto:sage [2024/07/24(水) 22:25:44.31 ID:mF9Tvkg9.net]: ベストな日付処理クレートについて議論しよう
990 名前：デフォルトの名無しさん mailto:sage [2024/07/25(木) 08:45:26.25 ID:q/t9CUhu.net]: おすすめクレートの話はしてほしいな～
991 名前：デフォルトの名無しさん mailto:sage [2024/07/25(木) 10:09:56.78 ID:P+cFrEvf.net]: クレートの話をしてくれー、と
992 名前：デフォルトの名無しさん [2024/07/25(木) 22:41:22.06 ID:zdgCFOr2.net]: クレートではないけれど今日リリースのRust 1.80でLazyCell, LazyLockが安定版に入ったよ
グローバルな変数を外部クレート無しで書きやすくなる
993 名前：デフォルトの名無しさん mailto:sage [2024/07/25(木) 22:49:30.69 ID:9YYk7vP+.net]: >>973
それ、OnceCell使ってたコードは全部置き換えた方がいい奴？
994 名前：デフォルトの名無しさん [2024/07/25(木) 23:18:37.32 ID:zdgCFOr2.net]: >>974
自分はそれを言えるほど詳しくないけど、必ずしも必要ではないと思う
依存クレートを減らせる点で嬉しいし、今から書くコードでは新しいものにして良いと思うけど、今使ってるものをすぐに置き換える必要があるとまでは思わない
特にライブラリを作ってる場合は、rustcを今日リリースされたばかりの最新バージョンに上げないとライブラリをビルドできなくなるということなので、もう少し待った方が良いかもしれない
995 名前：デフォルトの名無しさん mailto:sage [2024/07/26(金) 00:25:09.02 ID:/65SSmn2.net]: OnceLockからLazyLockへ移行すると
変数宣言と初期化関数が離れていた可読性の問題が解決するとともに
例えばget_or_initを一箇所にするために一つ関数を用意したりするなどしていた手間も省けるようになるね
そして何よりも最大のメリットはDerefによりアクセスできる利便性
996 名前：デフォルトの名無しさん mailto:sage [2024/07/26(金) 23:32:15.42 ID:/65SSmn2.net]: とりあえず定番のこのあたりを置き換えた
static RE: LazyLock<Regex> = LazyLock::new(|| Regex::new("...").unwrap());
static SE: LazyLock<Selector> = LazyLock::new(|| Selector::parse("...").unwrap());
997 名前：デフォルトの名無しさん mailto:sage [2024/07/27(土) 11:02:49.38 ID:WfV9QQMJ.net]: LazyLockよさそうね
998 名前：デフォルトの名無しさん mailto:sage [2024/07/27(土) 18:38:25.11 ID:U5WpGSyZ.net]: 俺の今日のハマりポイントを紹介

bindgenにC++のコンストラクタを作らせると、データが壊れる
よく調べたら公式ドキュメントのConstructor semanticsに書いてあった
https://rust-lang.github.io/rust-bindgen/cpp.html

コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので
struct内部を参照したポインタが変なところを参照してバグる
999 名前：デフォルトの名無しさん [2024/07/27(土) 19:30:58.99 ID:s18eFGvS.net]: C++も部分的に使えるとはいえ、FFIするならCのAPIにしておく方が無難な気はする
1000 名前：デフォルトの名無しさん mailto:sage [2024/07/27(土) 20:04:50.53 ID:U5WpGSyZ.net]: >>980
bindgenはFirefoxがプロダクトでたくさん使ってるって聞いて、いけると思ったんだ
Firefoxは大半がC++だから
1001 名前：デフォルトの名無しさん [2024/07/28(日) 15:27:45.35 ID:v6kdbv5j.net]: >>978
LazyLockさようなら
に観えた
1002 名前：デフォルトの名無しさん mailto:sage [2024/07/28(日) 15:29:40.57 ID:v6kdbv5j.net]: >>979
RustとC++は相性最悪
RustとCは相性良いバッチリ
1003 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 01:24:35.90 ID:xgbf/AIH.net]: >>979
この件って、RustはC++と比べて無駄にムーブするから遅いってこと？
1004 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 06:04:09.29 ID:RHAjweCG.net]: 無駄な移動は消える
cargo asmで生成コードを見ることでそれを確認できる
移動前と移動後のアドレスを表示させて最適化を阻害することで元は別々となる例も確認できる
1005 名前：デフォルトの名無しさん [2024/07/30(火) 12:06:12.26 ID:tiWzrJ23.net]: >>984

＞コンストラクタを抜けたとき、C++とちがってRustは値をムーブしちゃうので
＞struct内部を参照したポインタが変なところを参照してバグる

って書いてるのに、読解力無い人？
1006 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 19:02:27.28 ID:dzXOiSL/.net]: >>985
移動じゃなくてムーブね
ここまでのレスで使われてる述語を踏襲すればいいよ
1007 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 20:13:33.28 ID:VUdF4pDl.net]: >>985
最適化のかかり具合でバグが消えたり現れたりする嫌なパターンだな
1008 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 20:41:43.84 ID:+5mpqNgW.net]: >>986
Rustを使えばそんなバグは起きない
参照のライフタイムは参照先より長くなることがコンパイル時点で保証される

>>988
Rustならばそこでバグは起きようがない
1009 名前：デフォルトの名無しさん [2024/07/30(火) 22:41:22.15 ID:GjQxUZ/0.net]: >>989
本人じゃないのに出しゃばらせて頂きますが…。

Rust単体じゃなくて、C++との相性問題ですよ。相性最悪って書いてるんだから。
起きようがないじゃなくて、実際に起きてるらしいじゃないですか。

最適化で治るのなら大したことじゃなくても、デバッグ時にハマるの確実な類のバグ。

将来的に全部Rustで書けば起きないような問題も、過渡期の今は良く起きます。

「Rustを使えば」「Rustなら」。
そうでしょうけど、実際問題ライブラリがなければ既存のC/C++ライブラリ使う場面は多々あるでしょう。
（枯れたライブラリならなおさら）

これはRustに限らず、後続の言語全てが抱えている問題です。
1010 名前：デフォルトの名無しさん [2024/07/30(火) 22:49:06.91 ID:MqLM+D1V.net]: 最適化じゃなくて単に移動の問題
Box::newで要素を直接ヒープに作れない (いちどスタックに作られてからコピーされる) のと同じで、コンストラクタを抜ける前に構造体が maybeuninit::assume_init で移動する
その上で構造体のアドレスがC++のメソッドにthisポインタとして渡される際に問題を引き起こす、というように思える
だとすると最適化の有無は関係なく起こる気がする

ついでにいえば >>987 もあまり意味のない発言で、移動はムーブの訳語でもある (例えばC++の仕様の訳語に移動コンストラクタという表現がある) し、そもそもこの問題はムーブセマンティクスによるものでもない
これはStringやVecが持つリソースを所有権ごと移動することで効率的に別の変数に割り当てるもので、構造体のアドレスのようなローレベルなものとは違うかと
1011 名前：デフォルトの名無しさん [2024/07/30(火) 22:59:00.85 ID:MqLM+D1V.net]: 移動とムーブが仕様として別物だというなら、移動は英語でどう表現されてるんだ？
1012 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 23:00:06.83 ID:L/ylOhaJ.net]: >>990
それはRust単体では全く発生しない問題だね
C++とRustを併用する時にRustの知識を持たない人がハマるという話
FFI部分は両者の概念と挙動の違いの知識を持った人が作るべきだね
1013 名前：デフォルトの名無しさん mailto:sage [2024/07/30(火) 23:13:56.95 ID:EnloT7kO.net]: >>979
>>値をムーブしちゃうのでstruct内部を参照したポインタが変なところを参照してバグる

Rustでそのような自己参照はムーブでライフタイム切れとなるためバグは発生しなくて
自己参照を保ちたいならば値がムーブしなければよくて
値がムーブしないためにはスタック上でそのまま使うかヒープ上に確保して使えばよくて
それを保証するためにRustではPinという枠組みがあって安全に取り扱えるようになってるよ
1014 名前：デフォルトの名無しさん [2024/07/30(火) 23:19:18.00 ID:MqLM+D1V.net]: >>994
bindgenの作者に言ってあげればいいと思うよ
ついでに改善したコードをPRしてコントリビュートしてみてはどうだろう
使用者のミスを擦るよりもずっと有意義なはず
1015 名前：デフォルトの名無しさん [2024/07/30(火) 23:48:00.88 ID:dZ3/RfBM.net]: 同意
1016 名前：デフォルトの名無しさん [2024/07/31(水) 11:32:49.64 ID:yHR2oE13.net]: 結合が密過ぎないかこの言語
1017 名前：デフォルトの名無しさん [2024/07/31(水) 11:35:31.65 ID:yHR2oE13.net]: >将来的に全部Rustで書けば起きないような問題

さっさと仕事しろおまいらってことですね判ります
1018 名前：デフォルトの名無しさん [2024/07/31(水) 12:10:03.24 ID:yHR2oE13.net]: >>985
Pin
1019 名前：デフォルトの名無しさん [2024/07/31(水) 12:10:59.00 ID:yHR2oE13.net]: Pin<Arc<T>>
1020 名前：1001 [Over 1000 Thread ID:Thread.net]: このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 65日 5時間 29分 33秒
1021 名前：過去ログ ★ [[過去ログ]]: ■ このスレッドは過去ログ倉庫に格納されています

[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef