Rust part15

**デフォルトの名無しさん** · 2022/05/12(木) 18:28:20.99

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

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

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

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

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

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

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

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

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

**デフォルトの名無しさん** · 2022/06/12(日) 20:47:24.48

>>577
一般的に参照返すイテレータ類を実装する場合の注意点として、
　1. let x0 = x_iter.next();
　2. let x1 = x_iter.next();
　3. ここで x0 の指す値を使う
順にこのような使い方をした時の挙動として、以下4パターンが考えられる
　A. ✕ 実行時エラーとなる
　B. ✕ x0の指す値が変化してしまう (次のx1の指す値と同一になってしまう)
　C. ○ x0もx1もそれぞれ正しい値を指す
　D. ○ コンパイル時エラーとなる

Rcとget_mut()を使った>>511のコードがNGのパターンA.で、これを避けるために、
Rc<RefCell>を使う提案のようだが、それもNGのパターンB.となってしまう
Rcとmake_mut()を使えばパターンC.となり、これがRc利用の場合の解となる

しかし参照を返すイテレータ自身がmake_mut()でclone()するのは役割として過剰である
切り分けとしてはイテレータを使う側が必要に応じてclone()するのが望ましい
そういうコードへ適切に誘導できる道が、コンパイル時エラーで示すパターンD.

具体的には、似非IteratorであるStreamingIteratorを用いるか、
Rust本命のGATsを用いたLendingIterator (＝GATs適用後のIterator) を用いると、
clone()が必要な場面ではコンパイル時エラーにより知らせてくれる
もちろん普通にnext()ループ内の利用ならばclone()の必要なくコンパイルが通る

**デフォルトの名無しさん** · 2022/06/12(日) 20:59:35.22

実際に >>618のOverflowingAddAssignを用いてLendingIteratorで実装すると
以下のようになり、GATsを用いている以外は現状のIteratorともちろん同じ形
自己参照を返せるようになった点のみ異なる

impl<T: OverflowingAddAssign> LendingIterator for Fibonacci<T> {
　type Item<'a> = &'a T where Self: 'a;

　fn next<'a>(&'a mut self) -> Option<Self::Item<'a>> {
　　if self.is_overflow {
　　　return None;
　　}
　　if self.is_first {
　　　self.is_first = false;
　　} else {
　　　self.is_overflow = self.p.overflowing_add_assign(&self.q);
　　　std::mem::swap(&mut self.p, &mut self.q);
　　}
　　Some(&self.p)
　}
}

is_first処理は >>511のコードでの「iter::once(p.clone()).chain(...」部分であり必須
また、前述のようにBigUintで用いれば is_overflow が常にfalseのため最適化で消えて、
値の更新部分は「self.p += &self.q」のみが残り非ジェネリックと同一コードとなる
したがって、上述のコードがどの型でも最善に動作するコードとなるだろう

**デフォルトの名無しさん** · 2022/06/12(日) 21:33:27.12

NAVERまとめを彷彿とさせるレス乙
3～4日もかけて頑張って調べたのは讃えるが
特質の異なるものを必要もなくジェネリック化することがアンチパターンだということに早く気づいてね

**デフォルトの名無しさん** · 2022/06/12(日) 21:51:32.06

これは同じものだからジェネリックでいいんじゃね

**デフォルトの名無しさん** · 2022/06/12(日) 22:02:56.78

>>620
構造体メンバーであるis_overflowが常にfalseであることが分かるほどコンパイラ賢いんだっけ？
実際に生成されるコード確認した？

**デフォルトの名無しさん** · 2022/06/12(日) 22:16:28.43

add系は#[inline]だから大丈夫

**デフォルトの名無しさん** · 2022/06/12(日) 22:22:02.34

>>624
構造体メンバの値はグローバル変数なんかと同じで関数外で値が変更される可能性があるので
メンバが特定の値しか取らないことを暫定として最適化するためには、
crateの範囲を超えてプログラム全体で値が設定されうる箇所が他にないことを確認するか
メンバが可視な範囲で確認する必要があると思うけど、
前者をやるためにはリンク時最適化が必要だし
後者ならメンバの可視性をLLVMに渡さないといけないと思う
rustcとLLVMはそこまでやってるの？

**デフォルトの名無しさん** · 2022/06/12(日) 22:54:00.11

rust結構面白いからマイクロソフトがVisualStudioでRustでWindowsFormを作れるようにしてくれればなあ

**デフォルトの名無しさん** · 2022/06/12(日) 22:59:17.60

>>618
それが>>566の2行目で書いてる工夫のことだよ
boolではなくchecked_add使ってOption<()>返すメソッドにしておけば?演算子でシンプルに書ける

**デフォルトの名無しさん** · 2022/06/12(日) 23:07:42.57

>>627
assignでない演算は生成のため内部でcloneが発生して無駄と既に結論が出ている

**デフォルトの名無しさん** · 2022/06/12(日) 23:11:14.31

GATがstableになるの意外と近い予定なんだな
年単位で先のことかと思ってた

**デフォルトの名無しさん** · 2022/06/12(日) 23:18:22.58

>>625
Rustでそれは起きない
書き換えるには所有権か＆mutが必要でコンパイラは全て把握している
更に構造体のメンバーはpub指定がない限り他者はアクセス不能
つまり今回ならばnext()しかメンバー書き換えしないとコンパイラは確定できる

**デフォルトの名無しさん** · 2022/06/12(日) 23:25:01.40

>>630
その最適化するのはLLVMだけどLLVMが最適化できるだけの情報を渡してるの？というのが聞きたいこと

**デフォルトの名無しさん** · 2022/06/13(月) 00:14:58.10

>>623
その通りRustコンパイラが賢いことを確認したよ
is_overflowが常にfalseとなることを察知してNoneを返すことが無くなったみたい
Noneが来ない利用側のwhile let Some(n) = iter.next()は無限ループのコードとなっちゃった
さらにwhile loopより後ろのコードは永遠未達と判断されて完全に消えた

**デフォルトの名無しさん** · 2022/06/13(月) 00:32:02.84

>>628
checked_add使うのはプリミティブだけだよ
BigUintはadd_assignで常にSome(())

**デフォルトの名無しさん** · 2022/06/13(月) 00:46:44.89

>>620
GATってIteratorとか既存TraitのAssosiate Typeに直接ライフタイム書けない仕様になったの？
LendingIteratorみたいに別のTraitを使わないといけないようならイテレータ関連の仕組みが2重なって使い勝手が悪い

**デフォルトの名無しさん** · 2022/06/13(月) 00:50:16.18

>>633
意味不明
Some(())/Noneにするならば>>618のbool値のコードで十分

**デフォルトの名無しさん** · 2022/06/13(月) 00:56:09.87

>>634
もちろん出来るようになる
今は無理だからRust公式ブログで解説された例に倣って仮にLendingIteratorとの名で定義して使うなどする

**デフォルトの名無しさん** · 2022/06/13(月) 12:04:19.24

>>632
おー、そんな賢いんだ。すごい
ちなみにfn mainとイテレータの定義は同じcrateに含まれている？
lib crateでイテレータを定義してbin crateから使った場合にどうなるかも気になる

**デフォルトの名無しさん** · 2022/06/13(月) 14:28:57.42

>>626
こういうMicrosoftからのサポートは俺も期待してる
VC++よりもRust書きたい

**デフォルトの名無しさん** · 2022/06/13(月) 17:16:12.55

やめてくれ
汚コードまみれになる

**デフォルトの名無しさん** · 2022/06/13(月) 19:44:34.63

乱数系のモジュールの仕様変更がかなりガッツリあったみたいなんだけど
Rustってこういうことよく起るの？
なんかWeb系みたいなノリを感じたんだが合ってる？

**デフォルトの名無しさん** · 2022/06/13(月) 19:57:14.15

なんのはなしだ

**デフォルトの名無しさん** · 2022/06/13(月) 19:58:13.01

>>640
人に読んでもらう文章は重要なところ省いたら読んでもらえないよ

**デフォルトの名無しさん** · 2022/06/13(月) 19:59:25.24

>>640
標準ライブラリで破壊的変更はほとんどない
外部crateなら概ねsemverに従ってるし lockfile の仕組みもあるから、
以前ビルドできていたものがビルドできなくなることもほとんどない

**デフォルトの名無しさん** · 2022/06/13(月) 20:37:45.98

>>638
サポートってどの程度のサポートを期待しているんだ？
MSがRustコンパイラー出せばWindowsのRust用フレームワーク出すんだろうがな
出さないなら、C/C++/C#のAPI/フレームワークをRustからとりあえず使えるようにしました
程度のサポートになるだろう。
期待しているのはRust用フレームワークであってRustからとりあえず使えるよじゃないだろ？

**デフォルトの名無しさん** · 2022/06/13(月) 20:37:53.20

>>643
あれ外部ライブラリか
しかし乱数系の標準ライブラリってまだRustにないのか
やぱ若い言語だなRust

**デフォルトの名無しさん** · 2022/06/13(月) 20:43:42.90

>>645
若いというか意図的に標準ライブラリから外してあるよ
理由は標準入りしてしまうと破壊的変更ができなくなって腐るから
だから将来的にも標準に入る予定はないと思う

**デフォルトの名無しさん** · 2022/06/13(月) 20:52:20.46

>>646
意図的に外してるの？
ふーん、それはそれで面白い

**デフォルトの名無しさん** · 2022/06/13(月) 23:01:34.06

>理由は標準入りしてしまうと破壊的変更ができなくなって腐るから

なんという本末転倒感

**デフォルトの名無しさん** · 2022/06/14(火) 00:25:58.88

基本的にRustはシンプルに最小限の言語構成部分しか標準ライブラリに持たない方針
つまり各プログラミング言語毎に標準ライブラリの意味合いや範囲が異なるのと同じ
だから乱数でも正規表現でも何でもRustでは外部クレートに存在する
非同期だって基本構成部分のasync/await/Futureは言語として持つけど
非同期ランタイムや非同期ライブラリは外部クレート

**デフォルトの名無しさん** · 2022/06/14(火) 00:42:56.77

OptionやResultの便利メソッドはどんどん追加されてるし別に標準ライブラリを最小限のものにしようとはしてないでしょ

**デフォルトの名無しさん** · 2022/06/14(火) 00:49:05.73

>>649
>最小限の言語構成部分しか標準ライブラリに持たない方針
俺もそんな方針だと思う
これが良いのかどうかは分んが。
標準ライブラリだとコンパイラ屋がコンパイラを出す限りサポート・メンテされるのが
他の言語では標準ライブラリなのが外部クレートだと、将来これをメンテする奴がいないになって
放置になり困ったになる可能性あるからな。

**デフォルトの名無しさん** · 2022/06/14(火) 01:01:42.50

>>650
それは最小限の意味合いの受け取り方が違っているだけで同じ
Option/ResultはRustにとって言語構成部分
そしてそのメソッドは強いて言えば多彩な制御構文にも相当する
だからRustの最小限の標準ライブラリに含まれているし必要性が認識されればメソッドも増える

**デフォルトの名無しさん** · 2022/06/14(火) 01:15:57.14

>>651
それは「サポートする人がいなくなればサポートされなくなる」という当たり前のことでRustとは別の一般的な話
どんな製品でも、どんなライブラリでも、どんな言語でも、同じ
そして基本構成部分を含むRust本体の改善＆メンテと、それ以外のライブラリのそれとは明らかに別の話たから切り離されているのも自然

**デフォルトの名無しさん** · 2022/06/14(火) 01:33:47.46

同じではあるがcargoの性質で余計に面倒な状態になってる。
この辺が低レイヤー向けと相性が悪い部分だな。

**デフォルトの名無しさん** · 2022/06/14(火) 02:16:38.57

>>654
低レイヤー向けのプログラミングをRustでしていて相性の悪さで困ったことはないが具体的に何だろう？

**デフォルトの名無しさん** · 2022/06/14(火) 02:19:17.55

聞きかじりだけどクロスコンパイルとかやりたかったらxargo使うもんなんじゃないの

**デフォルトの名無しさん** · 2022/06/14(火) 02:25:36.70

同梱されるライブラリが巨大な言語で
とんでもないクソ仕様が最初に入ってしまうとか
メンテナがいなくなったけど互換性維持で簡単に削除できないとか
色々あるからなあ

**デフォルトの名無しさん** · 2022/06/14(火) 02:36:05.02

>>652
確かにOptionやResultそのものは言語機能にも関わってくる基本的な構成要素だけど、
OptionやResultの便利メソッドは外部crateでも定義できるよね
また、HashMapやBTreeMapなどは "言語" の構成要素ではないし、
最近ではonce_cellという外部crateで実現できていたものをstdに取り込もうとしている
"言語" を構成する最小限の要素に絞るのであれば、これらは外部crateで実現すればよくて標準ライブラリに入れなくても良いはずだよね

おそらく、標準ライブラリに取り込むものは厳選してコンパクトさを保つことを前提に、
広く使われていてAPIが安定しているものは取り込んでいくというスタンスなんだと思うよ

**デフォルトの名無しさん** · 2022/06/14(火) 02:42:44.72

あー、rustで書かれたプログラム全体の中でのデファクトスタンダードとかお作法とかも含めて言語って言っているのかな
そうなのであれば特に異論ないです

**デフォルトの名無しさん** · 2022/06/14(火) 02:45:28.28

マンパワーが足りないから選択と集中で切り捨ててるだけ
利用者がそれを受け入れてるのは切り捨てた部分をコミュニティで支援するからコア機能の開発に力を注げってこと

**デフォルトの名無しさん** · 2022/06/14(火) 02:53:05.21

>>657
iostreamのことかああああ！！

**デフォルトの名無しさん** · 2022/06/14(火) 03:08:52.27

>>661
アレをRustに取り入れようという動きはないのかな？

**デフォルトの名無しさん** · 2022/06/14(火) 18:56:17.12

>>648
利便性ではなく一貫性で標準を決めているってことだろ

**デフォルトの名無しさん** · 2022/06/15(水) 14:46:59.83

>>658
Rustの利点はOption, Resultがmatchなどの構文で評価できる事、演算子もあるが演算子オーバーロードができる言語であれば同様のことができてしまうがC++23とか26とかで提案されていたinspectはmatchそのもの

**デフォルトの名無しさん** · 2022/06/16(木) 15:29:08.46

Rustの活用でElectronよりも軽くて速いアプリフレームワーク「Tauri」が安定版に

まずはデスクトップから。モバイル・Webへの対応も進行中

https://forest.watch.impress.co.jp/docs/news/1417148.html

**デフォルトの名無しさん** · 2022/06/16(木) 16:07:33.42

TauriとYewで純正Rustデスクトップアプリ開発か、
あるいはTauriとVue.jsでフロントエンドのみJavascriptでデスクトップアプリ開発か、

**デフォルトの名無しさん** · 2022/06/16(木) 16:51:56.72

Tauri + Vite + Vue 3 + Vuetify 3でデスクトップアプリ開発オラァ！！！

**デフォルトの名無しさん** · 2022/06/16(木) 19:39:52.77

そういやAtom開発者がRustで書き直した究極のエディター「Zed」はどうなったんや。
https://forest.watch.impress.co.jp/docs/serial/yajiuma/1374/986/amp.index.html

**デフォルトの名無しさん** · 2022/06/16(木) 19:54:27.31

>>665
PC Watchが報じるほどのニュースか、これ？

**デフォルトの名無しさん** · 2022/06/16(木) 20:36:05.07

>>668
>>UIフレームワークには、GPUを活用した新設計のものを用意。このフレームワークは「GPUI」と呼ばれている。

これがどうなるかだな

**デフォルトの名無しさん** · 2022/06/16(木) 20:52:57.67

フレームワークおじさんきちゃったか

**デフォルトの名無しさん** · 2022/06/16(木) 21:28:18.61

rust製フレームワークの話なら歓迎、jsは該当スレでよろ

**デフォルトの名無しさん** · 2022/06/16(木) 22:27:59.11

>>670
俺的にはそれなんかバックにC/C＋＋のVulkan系を用いたものって気がするんだよな

**デフォルトの名無しさん** · 2022/06/17(金) 01:45:23.89

rustでgpuなんか使い始めたらライブラリぶっ壊れまくるぞ

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

？

**デフォルトの名無しさん** · 2022/06/17(金) 15:39:33.09

俺も今日からラスタシアンだからよろしくな
シャドーイングいいねアンダースコアで区切った同じような名前の変数が同一スコープ内に増え続けるのが嫌でイライラしてたらからこの仕様はめちゃ好き

**デフォルトの名無しさん** · 2022/06/17(金) 17:57:54.34

>>676
カタカタで書くとラステイシャンかラステイションだからよろしくな

**デフォルトの名無しさん** · 2022/06/18(土) 06:02:27.98

全然関係無いんだけど
最近の言語って使ってる人達に名前つけるじゃん
パイソニスタとかPHPerみたいな
CとかC++にもあるのかなー？とか考えてた時に思い出したんだけど
Pythonでモヒカンとか言ってる人達いるじゃん
アレの語源は何なの？

**はちみつ餃子** ◆8X2XSCHEME · 2022/06/18(土) 11:43:40.01

>>678
Python 関連の用語としては知らんけど、これのこと？
https://ja.wikipedia.org/wiki/%E3%83%A2%E3%83%92%E3%82%AB%E3%83%B3%E6%97%8F_(%E3%83%8D%E3%83%83%E3%83%88%E7%94%A8%E8%AA%9E)

**デフォルトの名無しさん** · 2022/06/18(土) 11:52:07.94

モヒカン族とか、一部の人間が使ってるだけでネットではろくに聞かない言葉だね

**デフォルトの名無しさん** · 2022/06/18(土) 12:19:14.82

>>679
どうもありがとう
ネットスラングだったのか
でもPython界隈以外で聞いたことないや

**デフォルトの名無しさん** · 2022/06/18(土) 12:29:31.13

俺は本場海外の用語以外は一切使わない陰キャチー牛の日本人が勝手な造語の和製英語とかクソダサいからな

**デフォルトの名無しさん** · 2022/06/18(土) 12:41:40.55

2005～2010頃の技術コミュニティではよく聞いたけど
最近はアンチハラスメントポリシーに抵触するから使われなくなった

**デフォルトの名無しさん** · 2022/06/18(土) 13:28:43.26

Rust サビちゃん
Python ヘビちゃん

**デフォルトの名無しさん** · 2022/06/18(土) 13:35:45.47

サビちゃんでもありヘビちゃんでもありヘジたんでもあり職場では犬たん++

**はちみつ餃子** ◆8X2XSCHEME · 2022/06/18(土) 13:37:07.64

>>678
C 使いや C++ 使いのことは Cer とか C++er と書いたりすることはあるが、どう読むべきなのかわからぬ……。

**デフォルトの名無しさん** · 2022/06/18(土) 13:42:03.39

>>686
社畜

**デフォルトの名無しさん** · 2022/06/18(土) 13:48:09.17

この世の中あまたの言語があるのになぜCやC++でコード書くかと言えば仕事だから

**デフォルトの名無しさん** · 2022/06/18(土) 14:09:02.52

普段仕事でC++使わない俺からするとRustめちゃくちゃわかりやすくて触ってて楽しい
特に配列やコレクションの扱い易さが段違いだわ

**デフォルトの名無しさん** · 2022/06/18(土) 14:30:49.67

>>689
まあ他の言語触ると扱いやすくて気絶するから触るな

**デフォルトの名無しさん** · 2022/06/18(土) 14:57:08.56

※お話の途中ですが蟹が通ります
　　　　　,､＿,､　　　　　
　三　 ( ´･ω･｀)　
　　三　/ヽ　/ヽ　　　　　　　 (V)　　(V)　
　　三ノ￣ゝ　　　　　　三ミ (´･ω･｀) ミ
　　　　　ﾀﾀﾀｯ　　　　　　　　　　　　　　　　　ｻｻｻｯ

**デフォルトの名無しさん** · 2022/06/18(土) 15:02:32.97

そのカニもらって食べちゃうね

**デフォルトの名無しさん** · 2022/06/18(土) 15:34:56.20

命名規則のガイドラインがスネークケースなのがC/C++に配慮した結果なのかなぁって気がするけどまぁ慣れの問題だから文句ないよ

**デフォルトの名無しさん** · 2022/06/18(土) 19:21:06.68

公式ドキュメントにRustは式指向言語ですってあるんだが式指向とはなんぞや？

**デフォルトの名無しさん** · 2022/06/18(土) 19:25:35.79

制御構文が文じゃなくて式になってて値を返すという意味かと

**デフォルトの名無しさん** · 2022/06/18(土) 19:54:48.42

終端にセミコロンつけたら式じゃなく文になっちゃうとか独特だよね
fn five() -> i32 { 5 }とかfn five() -> i32 { 5 };って書けた方が違和感ない気がするんだけどね

**デフォルトの名無しさん** · 2022/06/18(土) 20:32:50.72

Rustはラムダ引数の型推論が多くの他の言語とは異なって機能するんだよ

**デフォルトの名無しさん** · 2022/06/18(土) 21:11:11.71

最近、ゲームのRustが人気過ぎて検索に支障が出てる

**デフォルトの名無しさん** · 2022/06/18(土) 22:17:14.37

>>694
日本語訳は公式じゃないから
今はもう公式では式指向(expression oriented)という言葉は使われてない

式指向言語の意味を知りたければwikiでもどうぞ
https://en.wikipedia.org/wiki/Expression-oriented_programming_language

**デフォルトの名無しさん** · 2022/06/19(日) 00:35:13.44

VTuberやストリーマーの間で人気を博しているサバイバルゲーム「RUST」とは？
https://www.moguravr.com/vtuber-rust/

**デフォルトの名無しさん** · 2022/06/19(日) 01:08:17.73

Goを見習って、Rustlangで検索してくださいね

**デフォルトの名無しさん** · 2022/06/19(日) 05:08:01.71

rust lang OR 言語 -go

**デフォルトの名無しさん** · 2022/06/19(日) 07:36:52.36

Rustではboolを論理値と訳してるけど言語ごとに揺らぎがあるのはなんでだろうね
個人的に真偽値を使ってるけど真理値って解釈もあるしこれも定義は別で厳密には違うけどRustとしては解釈は同じで違いはないってことなのかな

**デフォルトの名無しさん** · 2022/06/19(日) 08:12:44.50

作った人が違うんだから揺らぎがあるのは当然だろ

**デフォルトの名無しさん** · 2022/06/19(日) 09:35:04.20

作った人というより訳した人の違い
Rustの日本語書籍でも統一されてるわけじゃない
論理値はもともとlogical valuesの訳語

>Rustではboolを論理値と訳してるけど
正しくは「The Bookの日本語訳ではBooleanを論理値と訳してるところがあるけど」

**デフォルトの名無しさん** · 2022/06/19(日) 09:50:34.90

手元のRust本見てみたけど真偽値も真理値もあるね
個人的には真偽値かな

**デフォルトの名無しさん** · 2022/06/19(日) 10:18:36.03

型は論理型と言いたくなる。真偽値型ってのもたまに聞くけど。

**デフォルトの名無しさん** · 2022/06/19(日) 10:32:50.28

ブール型でええやん

**デフォルトの名無しさん** · 2022/06/19(日) 11:02:28.95

the bookの日本語訳は翻訳の質が低いしアップデートもされてないからrustを本気で勉強したい人は読まない方がいいと思う

**デフォルトの名無しさん** · 2022/06/19(日) 11:11:00.25

https://jp.mathworks.com/help/matlab/logical-operations.html
> logical データ型を使用して boolean データを表現します

matlabではlogicalってデータ型があって中身は0か1
false, trueも結局はlogicalの0と1でしかない

https://doc.rust-lang.org/std/primitive.bool.html
> The bool represents a value, which could only be either true or false.
> If you cast a bool into an integer, true will be 1 and false will be 0.

一方rustではtrueもfalseも依然としてboolのまま

**デフォルトの名無しさん** · 2022/06/19(日) 11:23:29.55

ブール値のブールの意味を知らん人が多いのかもしれない
ブール値より真偽値型がいいな

**デフォルトの名無しさん** · 2022/06/19(日) 11:33:06.55

boolの意味なんか一般アメリカ人も知らんだろ

**デフォルトの名無しさん** · 2022/06/19(日) 12:03:30.22

>>710
値の呼び名の話と、内部表現の話と、castせず別の型の値として利用可能かどうかという3つの異なる話を混同してる

**デフォルトの名無しさん** · 2022/06/19(日) 13:11:53.53

ワットとかアンペアの語源を知ってるかって話？

**デフォルトの名無しさん** · 2022/06/19(日) 13:14:46.84

Rustを含めたほとんどの言語で
logical or/and/notと呼び
まとめてlogical operatorと言い
日本語で論理演算子と称するから
その対象となるbool値も論理値と訳すことが多く賛同だが
訳さずbool型とbool値のままが曖昧さがなくよいのではないか
もちろん文字列型も訳さない方がよい

**デフォルトの名無しさん** · 2022/06/19(日) 13:33:48.08

おまえらってほんとう用語の定義とかそういう話になると生き生きしよるな
あと「許可されないなんちゃら」みたいな法律家談義みたいな話

**デフォルトの名無しさん** · 2022/06/19(日) 13:35:46.28

>>714
自分の呼び方が正しいんだー
っていうキチ同士の争い

**デフォルトの名無しさん** · 2022/06/19(日) 14:12:32.07

>>714
ジュールとかニュートンのほうが先に頭に浮かんだ

>>716
とはいえ「所有権の複製」は見過ごせないって