次世代言語27 TypeScript Swift Go Kotlin Rust Nim

**デフォルトの名無しさん** · 2022/08/05(金) 08:26:38.87

スレタイ以外の言語もok

前スレ
https://mevius.5ch.net/test/read.cgi/tech/1655771266/

**デフォルトの名無しさん** · 2022/08/13(土) 14:10:23.92

>>374
エラー処理の要件次第ではbashだと辛くなりそうな予感がするんですが

**デフォルトの名無しさん** · 2022/08/13(土) 14:19:49.12

>>372
普通にストリームとかを使いっぱにしとけばいいんじゃね？
まともな実装ならその変数がGCで回収される時にクローズされるだろ

**デフォルトの名無しさん** · 2022/08/13(土) 14:49:04.30

>>326
日本が伊達にIT後進国じゃないってことだよな

**デフォルトの名無しさん** · 2022/08/13(土) 14:51:34.28

>>343
zig

**デフォルトの名無しさん** · 2022/08/13(土) 15:27:52.15

>>374
それだとファイルの末尾だと誤読しうる
おそらくファイル名の末尾の意味だろう

そういう処理は用途によってはbashスクリプトも当然使っている
ただし色んなエラー処理をしだすとシェルスクリプトでは面倒なこともある

そのためプログラミング言語を使う場合もある
Rustを使っているものもある

**デフォルトの名無しさん** · 2022/08/13(土) 15:36:28.85

>>377
GCはいつ起こるかわからない
そしてその使い方ではGCが起きるまでクローズが遅延される

すると色んな問題が起こる
OSリソースがその間占有され続ける
占有オープンなら他者が利用できないなど

GC言語を使うなら面倒でもdeferやusingなどで明示的に後処理するしかないだろう
もちろんC++やRustならばRAIIにより即座に解放されクローズ処理もされるため面倒な記述は不要である

**デフォルトの名無しさん** · 2022/08/13(土) 15:40:18.08

>>381
> GCはいつ起こるかわからない
> そしてその使い方ではGCが起きるまでクローズが遅延される
そんなことは分かってるよw
話の流れくらい読めよ

**デフォルトの名無しさん** · 2022/08/13(土) 15:56:23.29

>>382
RAII言語の方が優秀だと認識できているならばよろしい

**デフォルトの名無しさん** · 2022/08/13(土) 16:14:32.90

>>383
アホなの？
C# の using も知らん無能はいちいち絡んでくるなよ

**デフォルトの名無しさん** · 2022/08/13(土) 17:08:08.82

>>384
君は>>381を最後まで読まずに
途中で反射的に書き込んでいると分かったのでもういい
反省しなさい

**デフォルトの名無しさん** · 2022/08/13(土) 17:28:21.83

NoSQL最強おじさん笑
RAII最強おじさん笑

**デフォルトの名無しさん** · 2022/08/13(土) 17:30:58.15

>>385
お前は>>372に既に書いてあることをアホみたいに再度書いてるから揶揄されてることも分からん知能しかないことがよくわかったよw

**デフォルトの名無しさん** · 2022/08/13(土) 17:33:59.86

>>375
そんな雑なものがたくさんあるのに、Rustにすべきなんて言う人とはいつ迄も平行線な気がするよね。

**デフォルトの名無しさん** · 2022/08/13(土) 17:41:30.08

>>363
それが怠慢とかｗ
どこでメモリ（リソース）を確保してどこで解放するかをプログラマが選択出来なきゃ
それこそ自由度が無く使いにくい言語になる
GCがあるから解放しなくてもいつかやってくれるから明示的に書かないという思想が
正しいと思っているならおかしい

**デフォルトの名無しさん** · 2022/08/13(土) 17:50:27.94

>>388
Rustやれぇとか命令されても
命令を無視する自由度のある人間はいちいち気にしない
命令無視しようが平行線だろうが何も問題ない

**デフォルトの名無しさん** · 2022/08/13(土) 18:03:09.67

useとかusingとかdeferとか
書き忘れていたら実行前にエラーとなってくれればいいんだけどね
忘れずに書いていることに依存させる言語仕様はよくないね

**デフォルトの名無しさん** · 2022/08/13(土) 18:12:50.43

GCは結局メモリとGCの二つを管理しなきゃいけなくなって非効率なんじゃないか？

**デフォルトの名無しさん** · 2022/08/13(土) 18:14:07.67

量子プロセッサ時代のプログラミング言語とか、意義のある会議は出来ないものか。

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

ここ隔離スレなので特定のトピックに興味あるなら専用スレ立てた方が良いよ

**デフォルトの名無しさん** · 2022/08/13(土) 21:59:10.85

ファイルの自動クローズがRAIIで無条件かGCなので何らか明示指定かの話を見ていて思ったんだけど、
メモリの自動解放はこれまでGC言語だけの特権でGCにはデメリットもあれどメモリの自動解放という何もかもを上回るメリットが前面にあったのよね。
ところがGCがないのにメモリを自動解放するプログラミング言語が登場しちゃって危機感を覚える人も登場しちゃって、

**デフォルトの名無しさん** · 2022/08/13(土) 22:51:24.09

GCがない(?)のにメモリを自動解放するプログラミング言語は昔からありますが……C++と言いましてね。

C++で（Rustみたいに）スタックフレームに何でも押し込むスタイルにするとどうなるのかねぇ。

**デフォルトの名無しさん** · 2022/08/13(土) 23:40:22.03

重要なものがキャッシュに乗りにくくなるのでは？

**デフォルトの名無しさん** · 2022/08/13(土) 23:54:24.87

そもそもRustもC++も含め、RAIIは何でもスタックに積んでいるわけではない
スタック上の値のように振る舞うように作られているだけで、内部的にヒープにメモリを確保しポインタを保持しているケースが多い

**デフォルトの名無しさん** · 2022/08/14(日) 00:25:46.03

Rustは自動メモリー管理が売りなんだから、C++のように自由に何でも出来たらダメでは？

**デフォルトの名無しさん** · 2022/08/14(日) 00:49:36.36

JavaとHaskellの良いとこ取りのように宣伝されてたけど、悪いところを併せ持ってしまったのでは？

**デフォルトの名無しさん** · 2022/08/14(日) 07:17:26.98

>>396
C++はメモリを自動解放しない。
unique_ptrやshared_ptrを忘れずに利用し間違えずに使用した場合のみ自動解放されるが、
それはその正しく作られたプログラムがメモリを自動解放しているのであり、
C++という言語自体がメモリを自動解放することはない。
一方でGC言語やRust言語などはプログラムの記述と関係なくメモリが自動解放される。

**デフォルトの名無しさん** · 2022/08/14(日) 07:54:47.25

事実上今時のプログラムで生ポインタなんて使わないしアスペの>>401は知らんけど普通のプログラマにとってメモリー解放はC++程度で充分

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

>>402
それはプログラマーの問題。
プログラマーの作ったプログラムにより自動解放している。
C++という言語はメモリを自動解放しない。

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

>>401
一般ユーザーがめったに使わないnewで言いがかりつけるなよ。Rustのunsafeみたいなものだろ。

**デフォルトの名無しさん** · 2022/08/14(日) 08:30:27.75

はいはい、アスペは何を指摘されているかも理解できないからどうでもいいわ

**デフォルトの名無しさん** · 2022/08/14(日) 08:44:12.34

ムッシュムラムラ

**デフォルトの名無しさん** · 2022/08/14(日) 09:20:45.22

RAIIみたいなありふれたものじゃなくてxor mutabilityをアピールした方が良いのでは

**デフォルトの名無しさん** · 2022/08/14(日) 09:37:16.54

>>407
これ

**デフォルトの名無しさん** · 2022/08/14(日) 09:38:28.08

>>407
実運用としては難しすぎて逆効果だとわかっているから言わないんだよ。
あるいはそもそも理解していないか。

**デフォルトの名無しさん** · 2022/08/14(日) 10:03:55.97

>>409
難しすぎて逆効果ってどういうこと？
ワイRust大好きマンだけど、趣味ってだけで業務ではRust使ってないからよくわからない....

**デフォルトの名無しさん** · 2022/08/14(日) 10:19:19.22

>>410
もちろん難しいことはなくとてもシンプルな原理
そして実運用で非常に大きなメリットをもたらしている
Rustが大手IT各社に支持されている理由の一つ

**デフォルトの名無しさん** · 2022/08/14(日) 10:29:55.69

あくまでもOS開発の用途で採用されてるだけ

**デフォルトの名無しさん** · 2022/08/14(日) 10:38:15.56

>>412
Rustの世界的大規模な調査結果により
Rustの利用対象はサーバーサイド/バックエンドが最多で
以下クラウド、分散システム、WebAssembly/Webフロント、組み込みといった状況になっている

**デフォルトの名無しさん** · 2022/08/14(日) 10:43:52.82

>>413
ソースは？
大手企業は？

**デフォルトの名無しさん** · 2022/08/14(日) 10:48:15.10

>>414
>>413のソースは毎年調査が行われているRust Annual Survey Report

**デフォルトの名無しさん** · 2022/08/14(日) 10:58:46.14

>>407
XORじゃないけどな

**デフォルトの名無しさん** · 2022/08/14(日) 11:16:29.29

before == afterのことをimmutableというなら
==の定義とかあるんですか？
まさか、大手企業を観測すれば==の定義が分かると思ってるマッドサイエンティストはいないよね

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

>>416
一般的にデータ競合を起こさないための条件は
multiple readers XOR single writer
そしてRustも同じくこのシンプルな原則に従っている

**デフォルトの名無しさん** · 2022/08/14(日) 11:47:03.37

現実には複数の状態のストアに跨がる論理的な競合の方がずっと問題で、単一データの読み書きの競合なんてアトミック変数くらいで十分

**デフォルトの名無しさん** · 2022/08/14(日) 11:59:58.73

実行時に同時に読み書きしうるかどうかをコンパイラが厳密に検知することは不可能
Rustがやってるのは大幅に安全側に倒すアプローチで、それでいいんだったら関数型みたいにそもそもミュータブルなデータを共有しない、でも立派に対策になってるよね
実際それで十分なケースが殆どでしょ

**デフォルトの名無しさん** · 2022/08/14(日) 12:04:57.82

Rustはdata raceはふせげてもrace conditionは防げない
銀の弾丸でも何でもない

**デフォルトの名無しさん** · 2022/08/14(日) 12:09:32.20

>>419
アトミック変数を忘れたら競合する
さらにアトミック変数を使ってもそのコストがかかる

Rustでは静的にコンパイル時にデータ競合を必ず排除する
アトミック操作を必要とするならば指摘してくれる
multiple readers XOR single writerを守っていれば当然(コストの高い)アトミック操作を必要とせずにコンパイルが通る

したがってRustは他の言語よりもコストを低くデータ競合の安全性を常に満たせる

**デフォルトの名無しさん** · 2022/08/14(日) 12:11:52.89

並行処理をしてないのにいちいちいらない制約かけられる方がコスト高いわ

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

>>422
いつものキッズかな
単一変数のデータ競合が生じなくても多くのロジックは競合するんだよ

**デフォルトの名無しさん** · 2022/08/14(日) 12:17:06.31

並行処理を安全に実装するのが難しいから、需要があってGoとかRustみたいな言語が登場してるのであって、直列なコードしか書かないなら昔の言語でもよくね

**デフォルトの名無しさん** · 2022/08/14(日) 12:18:16.18

>>425
そうじゃなくて、並行処理をしている場合、現実には競合するタイミングが生じないと分かっていても制約がかかることになるんだよ
コンパイラは静的なスコープを検査することしかできないからな

**デフォルトの名無しさん** · 2022/08/14(日) 12:35:39.15

>>424
そんな当たり前のことで問題のすり替えをするのは行儀がよろしくない
>422では明確にデータ競合の話をしている

どの話であってもまずはデータ競合を起こさないことが必須
しかしこれまでの言語はプログラマー任せであり言語として実行前に静的にデータ競合を防ぐ機能を持たなかった
Rustはそれを実現するとともにコストの高いアトミック操作無しでもデータ競合を避ける形もサポートした

**デフォルトの名無しさん** · 2022/08/14(日) 12:48:55.73

>>427
多くの場合はより高水準の制御や抽象化を必要とするため、君が思っているほどデータ競合可能性の回避は重要じゃないってことだよ
制約に対して得るものが小さい

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

>>428
実際にそれらのプログラミングをしていればわかる
データ競合の回避は重要どころか必須

**デフォルトの名無しさん** · 2022/08/14(日) 13:29:25.97

やっぱRAIIを意識しないと会話が成立しないぞ

読みたい情報が消されたり書き換えられているバグよりも危険なのは
情報を記憶する領域自体が消滅しているバグだから
書き換えを制限する効果よりもmoveやdropを制限する効果を見なければ本質が見えない

**デフォルトの名無しさん** · 2022/08/14(日) 13:35:19.72

>>428
データ競合可能性の回避は重要か重要じゃないかではない
データ競合可能性の回避は必ずすべきこと
Rustを叩きたいからといってこれを重要じゃないと主張するのは頭が狂っている

**デフォルトの名無しさん** · 2022/08/14(日) 13:53:29.77

データ競合可能性の回避をしてないシステムやアプリって存在するの？

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

並列処理しなくてもmutable aliasingにまつわるバグは起こりうるよね
典型的にはコレクションのイテレート中の要素追加とか

これを防ぐ仕組みを整えたらうまいこと並列処理にも応用できたという話であってデータ競合を防ぐことが本質ではない

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

>>432
回避し切れてないシステムやアプリはそこそこ存在するけどw

**デフォルトの名無しさん** · 2022/08/14(日) 14:32:21.17

mutable aliasingはGC言語でも防げないからなぁ
これが一度Rustに慣れてしまうと他に戻れなくなる原因の一つかも
他言語も積極的に取り入れてほしいところ

**デフォルトの名無しさん** · 2022/08/14(日) 15:49:07.29

コレクションが変更されたら
影響のあるすべてのイテレータに何か通知するべき

ここで、すべてのイテレータのリストを強参照してるとメモリが解放されないバグを作れる
GC言語でも弱参照大事

**デフォルトの名無しさん** · 2022/08/14(日) 15:56:50.41

Rustはオワコンだろ。

**デフォルトの名無しさん** · 2022/08/14(日) 16:16:26.65

>>436
GC言語ってそこまでケアしてくれるのが普通なの？

**デフォルトの名無しさん** · 2022/08/14(日) 16:30:43.31

そういうレベルで設計する人たちだと、RustやReactなんかが良いのかもしれないな。
「レベルが高い」と思ってそうなのがアホだけど。
「弊社はアホが多いから、これで行くしかない」というのが正しい態度では？

**デフォルトの名無しさん** · 2022/08/14(日) 16:41:26.12

すばらしい洞察

**デフォルトの名無しさん** · 2022/08/14(日) 16:46:59.70

実際「自分はアホなのでバグのないC++は書けない」と思ってRust書いてるよ
年とともに集中力も維持し続けられなくなるし、コンパイラに助けてもらわないとどうしようもない

**デフォルトの名無しさん** · 2022/08/14(日) 17:03:40.00

昔の静的型付けvs動的型付け論争思い出すね
開発者は十分賢いと仮定しレビューやテストでバグを見つけられれば十分とする立場と、
実行前に機械的に抽出できるバグは潰しておきたい立場の違い

**デフォルトの名無しさん** · 2022/08/14(日) 17:06:11.09

Rustで「簡単」になるのははチームやコードを管理するリーダーやマネージャーで、実装するコーダーにとっては「簡単」じゃないのにな。

**デフォルトの名無しさん** · 2022/08/14(日) 17:08:43.26

そういうレベルだと、なに使っても同じでは？

**デフォルトの名無しさん** · 2022/08/14(日) 17:10:46.46

レビューやテストでなんとかできるなら現世代言語で十分だよね
次世代言語という観点では、実行前により多くの問題点を検出することや、検出できる問題の量を保ったままコード記述の自由度を高めることが期待されてることのひとつだと思う

**デフォルトの名無しさん** · 2022/08/14(日) 17:10:54.70

IT大手企業が揃って同じ主張
人手に頼るC++等ではバグを無くせない
良い人材を揃えているところでもミスをゼロには出来ないから言語による支援がある方が良い
メモリ管理でもデータ競合でも同じ

ソース
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/

Rustは、プログラムに必要なメモリーの確保や解放に関連するバグが生じない「メモリー安全」が保証されたプログラミング言語である。
それに対してこれまでのOS開発に使われてきたC/C++は「大規模な開発においてメモリー安全なコードを記述することがほぼ不可能」
（Microsoftのブログ「We need a safer systems programming language」より）なのだという。

GoogleによればAndroidに存在した深刻なセキュリティー脆弱性の70％近くがメモリー安全に関するバグに起因するという。
同様にMicrosoftも、同社製品に存在したセキュリティー脆弱性の70％がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と考えて、Rustを採用するに至ったというわけだ。

**デフォルトの名無しさん** · 2022/08/14(日) 17:12:42.24

イテレータなんてないし、for rangeで回ってくるのは常にコピーだよ。

**デフォルトの名無しさん** · 2022/08/14(日) 18:49:23.51

Rustはモダンとか言っておきながら今時セミコロン入力を強要するゴミ言語
セミコロン省略するとreturnを省略できる？何のメリットがあんのそれ
可読性が悪くなるだけだよね

JSみたいにフォーマッタで自動入力もできないしゴミ

**デフォルトの名無しさん** · 2022/08/14(日) 19:57:13.45

>>448
Rustを書いたことないか、チュートリアルレベルでしか触ってなさそう

**デフォルトの名無しさん** · 2022/08/14(日) 21:15:44.48

文法や記述は様々な言語をやっていれば誤差と慣れだけの問題となる
それに文句をつけるのは初心者と異常者のみ

そのRustに関して言えばセミコロンや中括弧(波括弧)は機能面で必要だからある
逆に例えば「 if (条件) 」の丸括弧は不要だから「 if 条件」

**デフォルトの名無しさん** · 2022/08/14(日) 22:57:09.94

関数型のElixir は、データを書き換えられない。immutable。
新規作成しかできない

だから、並行処理に強い

**デフォルトの名無しさん** · 2022/08/14(日) 23:52:55.91

>>448
こういう議論も地味に重要だと思う
セミコロンなしでreturn必須な言語の方が可読性高いのかな？
returnを書くことで読み手にとって何が明確になるんだろうか

フォーマッタでの自動入力って何？

**デフォルトの名無しさん** · 2022/08/14(日) 23:58:23.93

>>451
すなわち値を書き換えるたびにガベージを撒き散らしGC
さらにElixirにはGCされず溜まる一方のAtomがあり枯渇すると死ぬ

**デフォルトの名無しさん** · 2022/08/15(月) 00:30:10.08

文法はフォーマッタやコード生成、静的解析などのツールの作りやすさ影響してくるからあまり馬鹿にしない方が良い

**デフォルトの名無しさん** · 2022/08/15(月) 01:04:12.66

日本人は一部はセンスあるが
RustやElixer等メタプログラミング言語が理解できないやつが多すぎる

**デフォルトの名無しさん** · 2022/08/15(月) 01:17:24.43

外国人でも抽象的な概念についての難易度は同じだゾ・・・

**デフォルトの名無しさん** · 2022/08/15(月) 09:39:59.10

セミコロンを省略するとreturnになるわけではないぞ
・Rustでは式にセミコロンをつけると文になる
・ブロック({stmts}のこと)の最後の式が、そのブロックを評価したときの式となる
この二つのルールが原則で、関数のブロックの最後のセミコロンを省略すると、関数を評価した値になるってだけ

let a = {
let mut b = Builder::new();
b.add(foo);
b.add(bar);
b.build()
};
このルールのおかげでこのようなコードが書けるようになる(return文は関数から抜けるためにしか使えないので、ブロックの評価には使えない)
一時変数のスコープを最小限に抑えることができるし、mutableで宣言した変数を、スコープを抜けたらimmutableに戻すこともできる
慣れれば見やすいし、意味的なメリットも多い

**デフォルトの名無しさん** · 2022/08/15(月) 10:33:46.88

>>456
ウィキペディアの英語版と日本語版比べてみて、
メタプログラミングについて書かれている事が全然違うから。

日本は本当に遅れてる

**デフォルトの名無しさん** · 2022/08/15(月) 10:41:42.04

>>457
その意味不明な記法が可読性が悪くてゴミなんだが？
信者以外からはメリットを対して感じないよね。

この恩恵を受けるためだけにセミコロン全てにつけないといけないのめんどいんだけど。

**デフォルトの名無しさん** · 2022/08/15(月) 11:14:59.57

バカはバカを呼び寄せる

**デフォルトの名無しさん** · 2022/08/15(月) 11:41:54.68

>>459がどの言語の文法を理想と考えているのかが気になる
golang?

**デフォルトの名無しさん** · 2022/08/15(月) 12:05:46.45

なぜRustに対する批判が具体的なものじゃなくて、「意味不明」とか「不要」とか主観的で何を指しているのかわからないような言葉ばかりなんだろう

**デフォルトの名無しさん** · 2022/08/15(月) 12:17:22.73

文末のセミコロンが必須な主なプログラミング言語
C　C++　Java　Perl　PHP　など

この状況でRustのセミコロンを叩いているのはこれらの言語を知らない初心者？
しかもRustは文と値の区別のためセミコロンの有無を活用して意味付けしている

**デフォルトの名無しさん** · 2022/08/15(月) 12:21:25.57

>>463
最近の言語が一切なくて草
モダン言語はない方が普通でそれと逆行してるから批判してるんだが

**デフォルトの名無しさん** · 2022/08/15(月) 12:39:14.98

Python Ruby JavaScript Scala Kotlin あとなにがあったっけなぁ

**デフォルトの名無しさん** · 2022/08/15(月) 12:42:41.40

>>457
逆にセミコロンなしをデフォルトにしてセミコロンとかつけると式になるとかでもいいのでは？

その書き方ができると便利なのは否定しないけど、その恩恵を得るためだけに全てにセミコロン付けるのを押し付けるのは余計なコストだっていいたいわ

**デフォルトの名無しさん** · 2022/08/15(月) 12:52:23.38

セミコロンを省略可能にしたプログラミング言語は色々と苦しんでいる
昔からJavaScriptのセミコロン省略により起こる問題は有名だが
Goなどもセミコロンを省略可能な言語なので問題がよく起きている

例えばGoでは
foo := 111111111 + 222222222 + 333333333
が何らか長い行として長いので改行して書こうとして
foo := 111111111
　　+ 222222222
　　+ 333333333
と書いてしまうとこれは以下のセミコロンの省略と解釈されてしまう
foo := 111111111;
　　+ 222222222;
　　+ 333333333;
つまりエラーとなる

他にもGoでは
bar := []int { 111111111, 222222222, 333333333 }
が何らか長い行として長いので改行して書こうとして
bar := []int {
　　111111111,
222222222,
333333333
}
と書いてしまうとこれは以下のセミコロンの省略と解釈されてしまう
bar := []int {
　　111111111,
222222222,
333333333;
}
これもエラーとなる

**デフォルトの名無しさん** · 2022/08/15(月) 12:53:34.04

>>467のようにGoは「セミコロンが必須だけど、省略可で、自動セミコロン挿入される言語」であるため
うっかり改行すると自動セミコロン挿入により文法エラーとなってしまう

**デフォルトの名無しさん** · 2022/08/15(月) 12:53:34.61

Rustで文と式が混在するのは最適化のため？文でエラーが発生したときはどうなるんかね？

resultとかの戻り値用変数があると自然だけど、末尾呼び出し最適化が面倒になるので痛し痒し。

**デフォルトの名無しさん** · 2022/08/15(月) 13:06:38.69

>>467
それの何が問題なの？
文法エラーになるなら何の問題ではない、エラーにならずにコンパイルされて変な挙動をするとかだったら問題だけど

**デフォルトの名無しさん** · 2022/08/15(月) 13:10:39.72

>>466
文にセミコロンをつけると式になるって文法を整合性を保ったまま定義できるとは思えない....
1とかtrueみたいな一つの値は式として扱う
ifやmatchはデフォルトで文として扱い、セミコロンをつけると式になるって文法にすると
let x = f(if cond { ... } else { ... };)
みたいな文で、どこが文でどこが式なのか曖昧さを持ってしまう気がする

**デフォルトの名無しさん** · 2022/08/15(月) 13:14:43.30

構文解析の簡単さってかなり大事なことだと思う
language serverも軽くなるしコンパイルも早くなる
適当に書いてフォーマッタで整形するって書き方もできるようになる
セミコロンをつけるのが面倒なのは分かるけど、それ以上の恩恵があるのは事実

**デフォルトの名無しさん** · 2022/08/15(月) 13:15:05.13

文法エラーになってからわざわざ直すのは面倒くさくないの？
JS/TSでもASIの罠にはまらないように考えるほうが面倒だから基本セミコロン付けているな

**デフォルトの名無しさん** · 2022/08/15(月) 13:19:28.24

>>466
言語設計した事ある？
a = b の b は式だからお前の仕様だと ; が必要になるんだけどw

**デフォルトの名無しさん** · 2022/08/15(月) 13:22:56.61

>>469
Rustでは文は
Item(関数の定義や構造体の定義など)
LetStatement(let文)
ExpressionStatement(式にセミコロンつけたやつ)
MacroInvocation(hoge!();みたいにマクロの使用にセミコロンつけたやつ)
しかないから、そもそも文はエラーを生成しない
文の中の式がエラーを生成することはあるけど、文法上はハンドリングも式の中で行われる
https://doc.rust-lang.org/stable/reference/statements.html