Rust part10

**デフォルトの名無しさん** · 2021/04/02(金) 21:38:04.11

Mozilla発のRust言語のスレ

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

**デフォルトの名無しさん** · 2021/04/23(金) 20:51:53.23

C++ vs Rustスレでも作ってそっちでやってくれマジで
不毛すぎる

**デフォルトの名無しさん** · 2021/04/23(金) 21:04:58.31

>>249
そうだね、記述量の多い言語だと思う

**デフォルトの名無しさん** · 2021/04/23(金) 22:37:03.61

Rustのコンパイラと戦って勝ったコードは
シンプルでエレガントで簡潔なことが多い
らしい
mjk、

**デフォルトの名無しさん** · 2021/04/23(金) 23:34:43.49

linusはやっぱすげーな
洞察力が違うわ
もちろんその道の神的な存在とはいえ
たいして知らない言語の弱点を一瞬にして暴いて
論破できるのは凄い

**デフォルトの名無しさん** · 2021/04/24(土) 01:08:35.83

>>251
例えばどんなとき？

**デフォルトの名無しさん** · 2021/04/24(土) 01:20:53.45

どんなときもどんなときもRustがRustらしくある～ために～

**デフォルトの名無しさん** · 2021/04/24(土) 08:06:24.96

C++ vs Rust
https://mevius.5ch.net/test/read.cgi/tech/1619219089/

立てましたので以降そういうのはこっちでお願いします

**デフォルトの名無しさん** · 2021/04/24(土) 08:33:43.03

>>258
お前ずっと一人で「他所でやれ」連呼してる奴だろ
C++との対立構造はRustにとって無視できないテーマでしょ
正直C++とどう住み分けたら良いのかわかってない奴がほとんどなんだから

**デフォルトの名無しさん** · 2021/04/24(土) 08:39:09.80

C++とRustは対立なんてしてない
Rustが怖いC++お爺ちゃんがRustに噛みつているだけでしょ

**デフォルトの名無しさん** · 2021/04/24(土) 08:48:20.99

カーネルの件で完全に拗らせとるな

**デフォルトの名無しさん** · 2021/04/24(土) 08:54:35.43

> C++との対立構造はRustにとって無視できないテーマでしょ

お前のテーマなんてどうでもいいんだよ
よそでやってくれ

**デフォルトの名無しさん** · 2021/04/24(土) 08:59:24.96

一般的なテーマだってこともわからんのか。馬鹿だな。

**デフォルトの名無しさん** · 2021/04/24(土) 09:02:59.11

リナス「やっぱCが至高、C++もRustもクソ！」

**デフォルトの名無しさん** · 2021/04/24(土) 09:13:04.98

rustもpanicをコアから外せればいけると思うのだが
もろ言語のコアなんだよな
痛いところ突かれた

**デフォルトの名無しさん** · 2021/04/24(土) 10:06:12.73

言語の問題じゃなくてライブラリの問題では

**デフォルトの名無しさん** · 2021/04/24(土) 10:11:32.69

へーpanicってライブラリなんだ

**デフォルトの名無しさん** · 2021/04/24(土) 10:29:13.61

>>259
仮にその対立構造を認めるにしても
「雑に書くならC++のほうが楽」なんて、曖昧で基準も何も示されない話に真面目に付き合う奴はいないよ
そういう奴らのための隔離スレとして用意したから好き放題書き散らせばいい

**デフォルトの名無しさん** · 2021/04/24(土) 10:42:59.04

コード長の話でしょ？
どー考えてもC++の方が短いよ
んなとこで張り合ってもしゃーない

**デフォルトの名無しさん** · 2021/04/24(土) 11:44:33.91

3割ぐらいは長いな
https://benchmarksgame-team.pages.debian.net/benchmarksgame/how-programs-are-measured.html

median source code gzip (July 2018)
Ruby 568
Python 672
C++ 1044
C 1115
Rust 1319

**デフォルトの名無しさん** · 2021/04/24(土) 12:07:10.57

>>258
乙。次からテンプレ入りで

>>980
スレ立てよろ

==========
公式
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/

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

前スレ
Rust part10
https://mevius.5ch.net/test/read.cgi/tech/1617367084/
==========

**デフォルトの名無しさん** · 2021/04/24(土) 12:17:31.75

Rustしかまじめに勉強したことないけどいい言語だと思うよ

**デフォルトの名無しさん** · 2021/04/24(土) 12:21:15.48

>>272
C/C++で一度ひどい目にあわないとRustの良さは分からんよ
今はまだ分かった気になってるだけ

**デフォルトの名無しさん** · 2021/04/24(土) 12:39:27.31

Rustはコンパイルでひどい目にあうから問題無い
同じことだ

**デフォルトの名無しさん** · 2021/04/24(土) 12:56:02.52

Rustのコンパイラに怒られまくる奴は三流プログラマ

**デフォルトの名無しさん** · 2021/04/24(土) 12:59:06.14

Rustの文字列変数って、
str1 = str2;
のように書いた時、copyではなくmoveでしたっけ？

**デフォルトの名無しさん** · 2021/04/24(土) 13:03:33.00

String型ならmove、&str型ならcopy
文字列リテラルなら後者

**デフォルトの名無しさん** · 2021/04/24(土) 13:09:43.73

>>276
調べてみたら、やっぱり、
let s1 = String::from("hello");
let s2 = s1;
とすると、以後、s1は使用できなくなり、使用しようとするとコンパイルエラー
になるんだね。こうなるのは珍しいと言えば珍しい言語。
1. Javaだと、参照を入れるだけで同じ実体を指しているため、s2経由で変更してもs1が
　指しているものも変更される。
2. JS の文字列は primitive 型なので「コピー動作」となり、s2とs1は別の実体を
　指すことになり、一方を変更しても他方には変更の影響は及ばない。
3. MFCのCStringも意味的にはコピー動作なのでJSと似ているが、高速化のため、
　代入後に一度も書き換えなければ、文字列を入れているメモリブロックは複製
　されないし、コピーもされない。
4. STL(C++) の std::striingもMFCと意味的には似た動作。
5. BASIC言語でも、文字列はコピー動作。
6. Rubyの場合、Javaと同じで同じ実体を参照しているだけなので、一方を書き換えると
　他方も全く同じように書き換わる。コピーするためには、s2 = s1.dup; と書く。

つまり、
a. BASIC、JS、MFC、STL(C++)は似た動作。
b. JavaとRubyも似た動作。
c. Rustは、b の系統に似ているが、s1 が使えなくなるのでちょっと違う。

**デフォルトの名無しさん** · 2021/04/24(土) 13:13:27.35

>>278
無駄なことに時間使ってないでthe bookくらい読みなよ

**デフォルトの名無しさん** · 2021/04/24(土) 13:20:12.76

>>
C# は、「b.」の系統で、JavaとRubyと似た動作だね。

**デフォルトの名無しさん** · 2021/04/24(土) 13:23:38.54

>>279
いろんな言語をかじってしまうと、どれがどれだか分からなくなってしまうんだよ。
文字列の s2 = s1 の動作は：
a. BASIC、JS、MFC、STL(C++)は似た動作。中身をコピーする。
b. Java、Ruby、C# が似た動作。参照を代入するだけ。コピーしたければ明示する。
c. Rustは、b の系統に似ているが、s1 が使えなくなる。

**デフォルトの名無しさん** · 2021/04/24(土) 13:27:17.48

>>281
Javaの場合、Stringは参照しか出来ないが、Rustの場合は、「String型」だけでなく、
「Stringへの参照型」も使えるんだっけ (let s3:&String ??) ？

**デフォルトの名無しさん** · 2021/04/24(土) 13:36:44.63

>>281
C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、
moveで、それ以外の時は copy。
一方、Rustだと、「デフォルト move」なので、基本的には move 動作。
cooy したければ、x = y.clone; と書くのかな。
色々ややこしい。

**デフォルトの名無しさん** · 2021/04/24(土) 13:39:26.22

>>283
> C++11以降は、x = y と書いた時、y が捨ててよいと判断した場合は、moveで、それ以外の時は copy。

そんな親切け？？？
左辺値同士だと明示しないとmoveしてくれないだろ
最適化次第ではしてくれるの？

**デフォルトの名無しさん** · 2021/04/24(土) 13:43:36.80

>>284
えっと、関数の戻り値が構造体型(or クラス型)の場合、右辺値と解釈されるので、
s2 = func(xxx);
見たいにした場合は自動的に move代入されたと思う。
それ以外だと、たいていは、s2 = std::move(s1); のように書かなければ
copy代入になるんじゃないかな。
s2 = func(xxx).s;
のようにした場合も move代入になるはず。
自信は無い。

**デフォルトの名無しさん** · 2021/04/24(土) 13:47:10.36

>>285
RVOは全然違うぞ
s2の構築にコピーコンストラクタを使わなくなって早くなるというだけ
ムーヴコンストラクタはそもそも出てこない

**デフォルトの名無しさん** · 2021/04/24(土) 13:47:25.73

>>285
自分の記憶だと、一時オブジェクトも右辺値だから、
s2 = std::string("xxx");
ともし書いたとしたら、右辺は右辺値になるのでmove代入になるはず。
s2 = s3 + s4;
みたいにしても、右辺は関数の戻り地と解釈されるので右辺値になるので
move代入になるはず。

**デフォルトの名無しさん** · 2021/04/24(土) 15:48:01.23

Rustってコードをフォーマットしてくれる機能があるからいいね
これこそモダンな言語だと思う

**デフォルトの名無しさん** · 2021/04/24(土) 16:01:24.29

C++と比べりゃ大抵の言語はモダンだろうよ

**デフォルトの名無しさん** · 2021/04/24(土) 16:18:04.79

しーぷらぷらあきらめてどろっぷあうとした
ちんちんぶらぶらまるはだかなひとたちが
rustすぱぁとをきめるスレ

**デフォルトの名無しさん** · 2021/04/24(土) 16:38:27.41

lintツールも満足に使えない人が喜んでるのかね

**デフォルトの名無しさん** · 2021/04/24(土) 17:14:02.73

非Syncなデータに複数スレッドからアクセスするコードに警告だしてくれるlintある？

**デフォルトの名無しさん** · 2021/04/24(土) 18:12:05.46

へーそれコードをフォーマットしてくれる機能なんだ

**デフォルトの名無しさん** · 2021/04/24(土) 22:25:57.79

>>293
君は、松永の論文を読んだのかい？

**デフォルトの名無しさん** · 2021/04/25(日) 11:06:21.68

質問です

let a = 10;
let b = &a;
let &c = b;

としたときに変数cは数値の10になるのですが
cの前にある&は参照外しの効果があるということなのでしょうか？

**デフォルトの名無しさん** · 2021/04/25(日) 12:30:46.33

>>295
pattern matchとdestructuringでそうなる
3行目でbの型が&Tの場合に`&c`にマッチさせたらcの型はTになる
dereferenceの意味で「参照外し」と言ってるなら意味は違うかも

**デフォルトの名無しさん** · 2021/04/25(日) 13:38:30.57

>>296
横から失礼するけど、なるほど。
let &c = b;
は、C++の
int &c = b;
とはかなり違った解釈をされてしまうんだね。後者の場合、&は参照型の
記号で、cの型は、intへの参照型になる。Rustで似たことをしたいなら、
let c:&i32 = &b;
だったっけ？

**デフォルトの名無しさん** · 2021/04/25(日) 13:41:33.98

String::fromとString::newの使い分けを教えてください

**デフォルトの名無しさん** · 2021/04/25(日) 15:13:55.60

>>297
cも参照にしたいなら単純に
let c = b;
でいいはず

let &c = b;
は
let (x, y) = (1, 2);
と似たような代入式だからbが参照型（かつ被参照型がCopy可能）じゃないと
コンパイルできない

>>298
String::newは引数取らないで空文字列を作る
String::fromは引数に文字とか文字列を取って同じ内容の文字列を作る

リファレンス（↓）読みなさいと言いたいけどRustのリファレンスって
traitとか理解しないとなかなか読みこなせないよね
_ttps://doc.rust-lang.org/std/string/struct.String.html

**デフォルトの名無しさん** · 2021/04/25(日) 15:19:02.60

>>297
>let c:&i32 = &b;

>>295の続きならbがすでに&i32なので
let c = b; か
let c: &i32 = b;

C++でもStroustrupに従ってint& c = b;と書いとけば同じ意味にとれなくもない

**デフォルトの名無しさん** · 2021/04/25(日) 15:31:18.79

意図もわからずなんとなく動くからそのメソッドを使い、借用をつければなんとなく動くから
借用し、変更する予定はないけどmutし、ここはエラーだからとpanic!し、補足するなと言われているのに
catch_unwind/recoverして、血の涙で泣きながら渡されたソースをシコシコ直すおまいら・・・

**デフォルトの名無しさん** · 2021/04/25(日) 16:19:28.48

>>299 >>300
なるほど、Rustでの b は、C++で言えば「参照」ではなく「ポインタ」の「ようなもの」に
なっているので、
let a = 10;
let b = &a;
の状態だと、
let c = b; か
let c: &i32 = b; か
let c: &i32 = &a;
で c を b と同じような「Rustでの参照型」の変数に出来るわけね？

**デフォルトの名無しさん** · 2021/04/25(日) 16:55:56.06

>>302
C++で書き直すと、
int a = 10;
int *b = &a;
の状態だと、
int *c = b; か
int *c = &a;
で c を b と同じような「C++のポインタ型」の変数になる。
ということだね。

**デフォルトの名無しさん** · 2021/04/25(日) 17:24:01.78

>>301
割とこの未来はもう始まってるんだよな。。rust書き逃げは結構ある。。

**デフォルトの名無しさん** · 2021/04/25(日) 17:25:49.32

悪用できない道具など無い

**デフォルトの名無しさん** · 2021/04/25(日) 17:30:22.71

構造体があるじゃん
a.b.cの更新参照もってて
同時に
a.b.dの更新参照とって
両方更新しようしたら
aの更新参照が２箇所にあることになるからできないの？

使い物にならんくない？

**デフォルトの名無しさん** · 2021/04/25(日) 17:40:32.44

>>296
なるほど

match式と同じ様に振る舞うのね

**デフォルトの名無しさん** · 2021/04/25(日) 17:58:15.33

>>306
更新参照ってのが&mutのことならできる時とできない時がある

同じ関数内で &mut a.b.c と&mut a.b.d を取ることはできるけど
&mut a.b をとって &mut a.b.d を返す関数を呼び出した後は a.b.d にアクセスできない
これは関数呼び出し時点で a.b が borrow されると判断されるため

このあたりを何とかしようとする議論は昔からあるけど特に進展なし
https://github.com/rust-lang/rfcs/issues/1215

実用的にはデータ構造の設計を見直すか、RefCell でくるむのが良いと思う
後者は &a.b をとって RefMut を返す関数にするってことね

**デフォルトの名無しさん** · 2021/04/25(日) 18:57:01.34

文字列についてなんかわかりにくいのだけど
C++に例えると
strはchar a[len]
Stringはstruct String { long len; char* str;}
&strはchar* str=&a[2]
このイメージで問題なし？

**デフォルトの名無しさん** · 2021/04/25(日) 18:59:07.81

悪用できない道具など無いキリッwwwwwwww

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

>>308
細かいけど関数の例はRefMut返すより&RefCellで返す方が安全な気がする
RefCell本体の参照をシェアするだけなら二重で呼んでも大丈夫だし
RefMut作るのは変更が必要な瞬間だけに限定したい

**デフォルトの名無しさん** · 2021/04/25(日) 19:28:29.93

>>309
&strはlenも持ってる
fat pointerでぐぐれ

**デフォルトの名無しさん** · 2021/04/25(日) 19:34:37.74

RefCellについての良いドキュメントや、本などがあれば教えて。

**デフォルトの名無しさん** · 2021/04/26(月) 10:05:04.39

f3がコンパイルエラーになる理由がわかる方います？

fn f2<'a, 'b, T>(x: &'a &'b mut T) -> &'a T { x }
fn f3<'a, 'b, T>(x: &'a &'b mut T) -> &'b T { x }

&'b mut TがTに変換可能で
&'a Tから&'b Tが変換不可だから？

**デフォルトの名無しさん** · 2021/04/26(月) 12:08:58.70

>>314
‘aが’bをoutliveするかどうかわからないからじゃない？

fn f3<'a: 'b, 'b, T>(x: &'a &'b mut T) -> &'b T { x }

**デフォルトの名無しさん** · 2021/04/26(月) 12:53:56.61

リーナスのRustのパニックがどうのはCを前提としたプロジェクトとRustの流儀がマッチしないって話に見える
逆にRustの流儀に沿ってデザインされたシステムなら問題は起きない可能性もある
てかそういう研究はされていないのかな？

**デフォルトの名無しさん** · 2021/04/26(月) 12:57:40.62

全部rustで書けばいいってか。馬鹿すぎる発想だな。

**デフォルトの名無しさん** · 2021/04/26(月) 13:02:47.63

パニックってFFI Boundaryさえ越えなければベアメタルだろうが使っても問題ない認識なんだけど間違ってる？

**デフォルトの名無しさん** · 2021/04/26(月) 14:09:26.26

>>316
そのシステムの基礎を作るのがOSで、Rustの流儀に従うようにする
基礎の部分を作るために Rust の流儀を前提とした言語で書くのは出来ない。
C言語は素朴なマシン語に直るために基礎を作ることが出来る。

**デフォルトの名無しさん** · 2021/04/26(月) 14:16:19.84

>>318
別に使って問題ないし、ベアメタル用のパニックハンドラなんかもいろいろあるよ。

**デフォルトの名無しさん** · 2021/04/26(月) 14:33:09.14

>>313
https://doc.rust-lang.org/book/ch15-05-interior-mutability.html
https://ricardomartins.cc/2016/06/08/interior-mutability
https://stackoverflow.com/questions/30831037/

**デフォルトの名無しさん** · 2021/04/26(月) 15:35:40.97

>>317
いきなりLinuxやWindows級のOSを作るのは現実的ではないが
組み込み用のOS程度なら馬鹿げてはないだろう

**デフォルトの名無しさん** · 2021/04/26(月) 18:30:20.34

>>315
回答ありがとうございます
確かに'a: 'bを付けるとコンパイル通りますね
xの変換については
&'a (&'b mut T)
→ &'a T
→ &'b T ('a: 'b指定により可能)
という考え方で良いのでしょうか

**デフォルトの名無しさん** · 2021/04/26(月) 18:39:37.14

>>323
いや自分で書いてて全然理解できてないです
下記変換は無しですかね。。
&'a (&'b mut T)
→ &'a T

**デフォルトの名無しさん** · 2021/04/26(月) 20:00:38.89

>>324
&'a &'b T の lifetime は 'a と 'b の短い方になるから
むりやり書こうとすると min('a, 'b) みたいになる

'a: 'b というのは 'a が 'b より長生きするという意味で
この場合 min('a, 'b) = 'b になるので f3 が valid になる

なお、&'a &'b T については暗黙的に 'b: 'a とみなされてるからコンパイルが通る
('b: 'a の時しか &'a &'b T 型の値が作れないため)

**デフォルトの名無しさん** · 2021/04/26(月) 20:05:03.48

>>322
じゃあ自分で作ってみりゃいいじゃん。
linuxなんかにいちゃもんつけてないでさ。

**デフォルトの名無しさん** · 2021/04/26(月) 23:42:53.23

>>301
自分で書いてて全然理解できてない奴らが量産されて、キーボードを叩く拳に血が混じりながら
意味不明なコードを誰かが直す。なんというおそろしい未来かw

**デフォルトの名無しさん** · 2021/04/26(月) 23:56:56.13

linuxにいちゃもんつけてる人はいないが
rustユーザーがlinuxにいちゃもんつけてると主張する人はいる不思議

**デフォルトの名無しさん** · 2021/04/27(火) 01:41:47.11

来年は組み込みRust元年になるやで

**デフォルトの名無しさん** · 2021/04/27(火) 02:20:03.39

あわしろ氏もそう言ってますね。

**デフォルトの名無しさん** · 2021/04/27(火) 02:20:38.76

何で今年じゃないの？

**デフォルトの名無しさん** · 2021/04/27(火) 02:36:39.16

panicのせいで実質組み込みでも死んじゃったな
linusやりすぎだぞ

**デフォルトの名無しさん** · 2021/04/27(火) 02:51:16.77

>>332
Linux カーネルで受け入れられないからと言って組み込みで panic が使えないわけじゃないでしょ。

**デフォルトの名無しさん** · 2021/04/27(火) 08:06:21.79

>>325
https://play.rust-lang.org/?version=stable&;mode=debug&edition=2018&gist=4f6ac5931e40d5e3dcf41712634e9390
元ネタこれなんですが
min('a,'b)的な考え方だと確かにf3について納得できる気がしますが、今度はf1が通るのがわからなくなります

f1を&'a &'b Tの参照がひとつ外せて&'b Tと考え
f0は'b:'aなので&'b Tから&'a Tに変換可能と考えると
f2が通ってf3が通らないことが理解できない
rust難しい。。

**デフォルトの名無しさん** · 2021/04/27(火) 08:11:26.79

>>326
だから作るにあたって参考になる資料とか実装例はあるのかって話なんだが
OSを作るみたいな資料はあってもその多くはCとアセンブラを前提としているし
それを参考にしたらC流になってしまうだろ

**デフォルトの名無しさん** · 2021/04/27(火) 08:43:32.76

実用的なOSとしてはこの辺かな。
https://github.com/tock/tock

あとは研究論文レベルでは、Rustの所有権システムをOSの権限管理周りに使って堅牢なシステムを作ろう、みたいなのもある。

**デフォルトの名無しさん** · 2021/04/27(火) 12:44:22.23

こんなんCで書いてるのと変わらんだろ。。
https://github.com/tock/tock/blob/master/arch/cortex-m/src/lib.rs

**デフォルトの名無しさん** · 2021/04/27(火) 13:52:57.49

>>337
インラインアセンブリでもRustを使うとコンパイル時に強力なチェックが！
あるわけないよな…Cでいいと思います

**はちみつ餃子** ◆8X2XSCHEME · 2021/04/27(火) 14:21:05.00

OS 全体の中でも低レイヤ寄りの部分はしょうがないでしょ。
どうせほとんどインラインアセンブリなら C でもいいが Rust で駄目という理由にもならんし。

**デフォルトの名無しさん** · 2021/04/27(火) 15:07:33.38

>>339
Rustは書き辛いし、生成されるコードや意味解釈に闇がある。

**デフォルトの名無しさん** · 2021/04/27(火) 15:26:51.13

言語の設計思想をOS全体に広げて実用的に成功した例ってあるの？
LispOSみたいなのは全部失敗してるじゃん
Cはもともとアセンブラで書かれてたOSを高級言語で書き直せるように
言語自体を後から設計したものだからね
Rustがシステム記述言語として使われたいなら、Linusに意向に100%従って
言語仕様をどんどん書き換えていかないとダメ絶対

**デフォルトの名無しさん** · 2021/04/27(火) 16:09:23.12

ここまでRedoxの話を避けているのはなぜ

**デフォルトの名無しさん** · 2021/04/27(火) 17:15:40.85

Redoxとか使ったことないし……

**デフォルトの名無しさん** · 2021/04/27(火) 19:00:31.49

>>341
forth?

**デフォルトの名無しさん** · 2021/04/27(火) 19:17:36.18

forthとかなつかしいなオイ

**デフォルトの名無しさん** · 2021/04/27(火) 20:00:34.98

FORTH作者「FORTHには申し訳ないことをした…」
ホントだよ！
FORTHがきちんとケアされ続けた世界線を見てみたい

**デフォルトの名無しさん** · 2021/04/28(水) 00:25:46.13

forthって今も使われとるのだろか。。

**デフォルトの名無しさん** · 2021/04/28(水) 01:56:40.25

昔はＢＩＯＳとか forth で書かれてたけど今はどうかなー

**デフォルトの名無しさん** · 2021/04/28(水) 03:06:12.66

Rustは配列に添え字アクセスする時、必ず境界チェックされるよね？

**デフォルトの名無しさん** · 2021/04/28(水) 06:10:01.83

言語設計とOSが一体ていうのがどのくらいまでを指すかにもよるけど
Smalltalk は元々は言語=OSみたいなシステムだったな

**デフォルトの名無しさん** · 2021/04/28(水) 10:12:57.76

>>349
言語仕様的にチェックされるかという意味ならYes