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


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

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



1 名前:デフォルトの名無しさん [2022/04/17(日) 17:52:35.38 ID:KG26dcth.net]
スレタイ(順番はRedMonk準拠)以外の言語もok

前スレ
次世代言語24 Go Nim Rust Swift Kotlin TypeScript
https://mevius.5ch.net/test/read.cgi/tech/1647887021/

175 名前:デフォルトの名無しさん [2022/04/23(土) 09:12:54.44 ID:eZJZo8Wb.net]
Goはコンパイル言語なのにスクリプト言語のように扱える軽量さが最大の魅力だろ
Go並にエディタの補完が軽量でコンパイル爆速のコンパイル言語を俺は知らない

Rustはライフタイムが全然わからなかったし、コンパイル遅すぎて無理だったね
GCはあった方がいいに決まってるわ
開発時の生産性が圧倒的に違ってくる

176 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 09:17:17.05 ID:kd0LPi6/.net]
GoはCGo何とかしてくれればもっと使う気になれるんだけどな

177 名前:デフォルトの名無しさん [2022/04/23(土) 09:20:09.97 ID:eZJZo8Wb.net]
とにかくGoは頭の悪い人でもすぐにプロジェクトに参加できるぐらいに機能がシンプルに削ぎ落とされていてコンパイル爆速ってのがポイントな言語
それに対して〇〇の機能がないーって言っても仕方ないだろ

頭の悪い人でも使いこなせる言語じゃないと企業ではなかなか普及しないと思うよ

178 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 09:46:22.59 ID:o/e4rrgi.net]
https://without.boats/blog/notes-on-a-smaller-rust/
だれかここで言われてる言語作ってくれ

179 名前:デフォルトの名無しさん [2022/04/23(土) 09:52:47.90 ID:XZjzYuNa.net]
>>174
本当にその通りなんだけど、これだけは欲しかったみたいな機能も一緒に削られてるところが少しモヤモヤする
ジェネリクス(ようやく追加されたけど)とか代数的データ型とか

180 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 10:30:02.86 ID:19UflQcD.net]
>>172
ライフタイムがわからなかった、って、かなり知能が低い人じゃないとありえないと思うよ
そしてそのくらい低い人はプログラミングに向いていないと思う

181 名前:デフォルトの名無しさん [2022/04/23(土) 10:34:13.57 ID:WKX1mrZa.net]
ライフタイムはわかるけどこれがリージョン推論とかいった厳密な理論とどう対応しているのかがわからん
一般的なプログラマーはここまで理解しなくてもいいんやろうけど
なんでこんな単純なわかりやすい原則の背後にそんな謎な人口に膾炙されていない理論を導入しないといけないのかがわからんわ

182 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 10:59:59.69 ID:BgAX+6b6.net]
荒らしなし規制無し

3ch
NEXT2ch
45ch

ふたばちゃんねる
明和水産

183 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 11:09:11.96 ID:teuoZU8e.net]
>>178
ブロックスコープというあまりにも大雑把な大きな枠で扱うのではなくて
実際に使われている有効な範囲(リージョン)で細かく扱いましょう、というだけだよ
生存単位は前者で、借用単位は後者で細かく区切る
具体的コード例を含めた解説ページの例

Non-Lexical Lifetimes って?
https://qiita.com/_EnumHack/items/8b6ecdeb52e69a4ff384



184 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 12:06:36 ID:uMxflx63.net]
プログラミング言語「Erlang」を生んだジョー・アームストロング氏死去
なお、アームストロング氏は「なぜオブジェクト指向はクソなのか」という名文を残しています。

185 名前:デフォルトの名無しさん [2022/04/23(土) 12:41:02 ID:lKjOluUR.net]
>>177
プログラマーって言ってもOS作ったりドライバ作ったりする低レイヤーやってるのと、バックエンドやWeb系の高レイヤーやってるのはいるわけで
Rustは前者の人たちが使えばいいのでは?後者の人たちがRustがーとかイキってるの見ると笑ってしまう

後者の分野ではRustはGoに勝てないでしょう

186 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 12:48:09.21 ID:HJoWw7qN.net]
>>182
むしろGoは対象が狭くて短命に終わる言語
言語の機能不足で書きにくい上に速いわけではない
唯一のメリット(?)が仕様が簡素なこと

187 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:26:27 ID:o/e4rrgi.net]
>>182
勝ち負けの定義次第だけど後者でもrustの方が有利な場合はあるんじゃないの
discordのバックエンドの例とかあるよね

だいたいのケースでgoが適しているって主張なら分かるけど
特定の分野で常にgoの方が適しているというのは言い過ぎかと

188 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:31:57 ID:BV8u7mBP.net]
これだからRust信者は嫌なんだ...12年続いて厳格に互換性を保ってる言語が短命だって?
速いわけではないって、そりゃGCが裏で動いてメモリー解放をほとんど気にしなくて良い言語と比べれば、極限の速度では有利になるのは当たり前でしょ?
それでもC99やRustなどと比べても2倍も時間が掛かるわけではない、これを速いわけではないと表現するのは、自身でも気づいていないのか隠された悪意と偏見を持ちすぎてる。
むしろRustこそ後方互換を保つためなどと言いつつEditionなどという仕組みや、ボローチェックの強化なんて短命のコンパイルが通らないような事をして、短命で終わっている
今書いてるRustが10年後コンパイルが通るのかエラーになるのか全く見えない。普通の用途ではGoで十分という話に噛みついてくる
言語の表層的な機能をどんどん導入して直行性が無く、どんどん書きにくくなっていくのに苦労に見合う速度はC99以下。唯一のメリット(?)は意識高い系がたった1つの言語をやってればマウントできる事

189 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:40:48.60 ID:j+9QGcWO.net]
>>182
でも現実にWeb分野でもRustがじわじわと広まりつつあるよね
サーバ側はGoよりRustが高速で省メモリでGC負荷なしで有利
ブラウザ側は実用的となったWebAssemblyでRustが最適

190 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 13:46:57.71 ID:o/e4rrgi.net]
>>185
不勉強でよく知らないんだけどeditionやborrow checkerの強化でコンパイル通らなくなったcrateってどういうものがあるの?

191 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 14:42:18.80 ID:iqGYI4s5.net]
長文に構うなよ

192 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 17:59:39.00 ID:Yf3QCfCm.net]
>>176
同感
必須機能が足りな過ぎてGoはプログラミングが修行のように辛い
C言語で何でも書けるというのと同じで書けるけど辛い

193 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 18:14:41.34 ID:DP+h97oH.net]
>>186
コンビニに行くのにF1とかソーラーカーは要らない定期。どれだけ早かろうが省エネだろうが。
JavaやC#はセダン〜バスみたいな感じかな。
Goは原付2種みたいなもんでしょ。
まず主戦場も違えばドライバーも違う。



194 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 18:17:56.69 ID:qKl7QP1V.net]
>>186
それでお前は使ってるの?
Reference Types使ってもパフォーマンスがjsに比較してカスな件どうなった?

195 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 18:21:30.06 ID:FZleZnGe.net]
>>191
え?
JSとは誤差
そして何か処理するコード次第で圧勝

196 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:02:24.78 ID:qKl7QP1V.net]
もう一回貼っておきますね

https://zenn.dev/igrep/articles/2021-11-wasm-reference-types

PythonにおけるCFFIみたいな用途で使う分にはきっと問題無いんだろうね
特定の目的に対してはぴったりはまるんでしょうが
それを何の前提も付けず単に「実用的」と呼ぶのは誇大広告ではないんですかね

197 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:03:19.39 ID:X7wDySqh.net]
最小限で考えると
Cにあとひとつ何かを加えたものでやっていけそう
Cに関数のオーバーロードがあればやっていけそう
コンテナクラスもほしいけどOOPを持ち込んでしまうので今回はパス
あくまで
void add(struct vector_int *v, int value)
void add(struct vector_float *v, float value)
というふうに関数と構造体だけで頑張っていけそう

198 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:36:04.43 ID:ugaeg6U2.net]
Cに拘ってる奴は本気でCが使いやすいと思ってるのか冗談で言ってるのか

199 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:53:30.81 ID:texCpgrl.net]
go よりはcのが好きかな

200 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 19:57:28.78 ID:stnqwczt.net]
>>195
下手な増改築だらけのC++よりCが良い
LinuxのLinusも同じ意見

201 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 20:15:34.17 ID:qKl7QP1V.net]
C言語にオーバーロード?
結局C++みたいにABI建て増ししてマングリングしないといけないやつじゃん

202 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 20:18:18.40 ID:o/e4rrgi.net]
Cは_Genericで頑張れば

203 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 21:14:20.68 ID:FKp57Oo8.net]
個人的いはCにがんばってほしい



204 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 21:39:38.45 ID:X7wDySqh.net]
>>199
> _Generic

(´・∀・`)ヘーそんなのあるんだ勉強になりました
これあったら十分やわ

205 名前:デフォルトの名無しさん mailto:sage [2022/04/23(土) 21:51:54.89 ID:w3sxk/eA.net]
ジェネリックってプログラミング言語によって指すものが異なってるよな
異なるといってもレベルの低いもの高いもの玉石混交という意味で

206 名前:161 mailto:sage [2022/04/23(土) 23:08:55.47 ID:dSfqqc1i.net]
IoT, AI でも、Elixir もある

Nerves は、最小のLinux, Erlang を含む、組み込み向けOS

Nx はテンソル用。
TensorFlow, PyTorch のフロントエンド

Erlang VM のFFI で、他言語のモジュールも使える

207 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 00:35:10 ID:tW7+nz8n.net]
Cは文字列が弱点だった
ちゃんとした文字列の型があればもっと便利だったとおもう

208 名前:デフォルトの名無しさん [2022/04/24(日) 01:36:20.84 ID:bAmVid1d.net]
nimはもっと広まって欲しいかな。できればpython置き換えるくらいに。

209 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 06:41:49 ID:4pJnSfn9.net]
>>197
てかLinusはそんなにその言語がいいと思ってるならそれでお前がなんか作ればいいだろって話をしてるな。
ここの連中なんかはまさにそんな感じだが。

210 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 09:27:58.32 ID:FwnGDc6j.net]
これはなかなか面白い記事だった
原点回帰というか、ここのスレでの議論にも参考になると思う
お前らの感想を聞きたい

How the C programming language has grown
https://opensource.com/article/22/3/how-c-programming-language-has-grown

211 名前:デフォルトの名無しさん [2022/04/24(日) 13:05:32 ID:LSLifE01.net]
結局言語は道具。結局は何を作るかなんだよ

212 名前:デフォルトの名無しさん mailto:shuang777gm@gmail.com [2022/04/24(日) 14:03:27.44 ID:plOa7TFC.net BE:557647423-2BP(0)]
img.5ch.net/ico/2iyou_2.gif
ネイティブ言語に変換できるビジュアルプログラミング言語とかいいと思う
オブジェクト指向とかわかりやすいだろうし。
唯一問題なのはマウスとキーボードをせわしなく行き来することかな
以前Blockly使ってそんなの作ったけどソースコードどっかやっちゃった

213 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 17:21:57.86 ID:uNEChMqn.net]
なんだァ?てめェ……



214 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 17:26:29.56 ID:K5BkO09u.net]
そうです、わたすが変なおじさんです

215 名前:デフォルトの名無しさん [2022/04/24(日) 18:16:43.21 ID:bl0Rasps.net]
Rustのスレ複製おじさんが暴れまわってるから怖くなっちゃって見てないわ
あんなスレ見てたら気がおかしくなりそう
ここはまだまし

216 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 19:14:30 ID:tfR0akyF.net]
頭おかしなるで

217 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 19:46:35.09 ID:gbNK0/9l.net]
>>181
「なぜオブジェクト指向はクソなのか」
1データ構造と機能は一緒にすべきではない
2すべてがオブジェクトである必要があります。
3データタイプ定義はあちこちに散らばってしまう
4オブジェクトはプライベートな状態を持っている

218 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 20:04:13.90 ID:tW7+nz8n.net]
最近はモジュールがまた流行ってるよね
rustもGoも自分から見るとモジュール指向に見える

自分はモジュール型からOOPに進化した過程を知ってるから正直モジュール型は好きじゃない

219 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 21:17:36.80 ID:slsDzRA2.net]
>すべてがオブジェクトである必要があります

C++やJavaみたいにすべてがオブジェクトじゃないオブジェクト指向言語なんていくらでもあるじゃん

220 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 21:49:22.71 ID:+4D6Qx5V.net]
>>216
そういう意味じゃないよ
https://gist.github.com/posaunehm/4087971

221 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:02:13.94 ID:4j4sWWkv.net]
真のオブジェクトっていうのは、一つのスレッドみたいなもので他のスレッドとの通信をメッセージパシングでやりとりするものと言っていたような
一方、普通にいわれているオブジェクト指向というのは単なるプログラミングの書き方の効率化の手法にすぎないって話
つまり、継承という方法で差分だけ書いていけるようにすることによる効率化だけの話だってこと。

222 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:04:35.47 ID:uNEChMqn.net]
差分プログラミングならまあクソでしょうね

223 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:06:02.75 ID:22aYjb+I.net]
今のオブジェクト指向継承あんま使わなくね?



224 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:09:28.03 ID:HH2OM4Tz.net]
むしろ継承はクソすぎて足を引っ張る
そのためGoやRustなどの言語ではclassを廃止というか最初から採用しなかった

225 名前:デフォルトの名無しさん mailto:sage [2022/04/24(日) 22:27:33.03 ID:L+Cr+2nK.net]
>>216
一言でいえば、プリミティブ型のことを言ってるんじゃなく(オブジェクトに)メソッドがぶら下がる粘着性を言っている。

いまどきの言語はRustやGoならstructで、Goならダックタイピング、Rustならクレートによるimplでそのデータを扱う機能実装を行うが
さらに考えを推し進め、D言語などでは(Pythonのself引数のように)データを引数に取るUFCと呼ばれる使い方も出来る。
関数が第一級の言語要素という考え(第一級関数)は、関数型言語には必要不可欠とされmap/reduceなどの高階関数でも
常用され、クロージャ・関数オブジェクト・無名関数と幅広く展開される。
OOPLとの明確な違いは、Classに対するオブジェクトにmethodという関数が束縛をされていないことである。もちろん上記の言語は
OOPSをサポートするが、それは多態を表現できるだけの意味しかない。

以上、D言語の宣伝です。

226 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:02:30.63 ID:m7DPUXtY.net]
>>222
> Rustならクレートによるimplで

ちょっと惜しい
『トレイトによるimpl』が正しい
その後にD言語は更に進んでいるとの宣伝と書いてあるようだが
Rustにも当てはまることばかりなので違いがよくわからない

227 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:27:04.32 ID:GF+5hMbb.net]
DのUFCSは任意の関数に適用できるけど
Rustは第一引数がselfなassociated functionだけだよね

228 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:33:35.96 ID:sDr1xuuT.net]
typescriptでclassを使わないでやったときに無限にf(g(h(x)))みたいに書いたなあ
tsにもほしいわ

229 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:34:27.96 ID:LqFJ2u6k.net]
どうしてDって今のgoやrustみたいにならなかったの?

230 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:35:54.45 ID:dSrWC4pO.net]
DのUFCSもメンバ関数やネスト関数などには適用できない制限がある

231 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:39:26.69 ID:cR9N6Lw+.net]
UFCSなんかなくても最初の引数の型に対してメソッド定義するだけで目的達成可能
グローバル名関数を増やして名前空間を汚さずともその型のメソッド定義がベター

232 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:47:38.84 ID:pTvSoM83.net]
>>225
GoやRustはclassなんか無くても各型に対してメソッドを定義できるのでそういうことを招かずに済むのよ
UFCSのメリットはメソッドチェーン記法が可能になることだから最初からメソッドを定義すればいいものね

233 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:55:00.32 ID:sDr1xuuT.net]
>>229
structかenumは定義する必要あるじゃん
tsのtypeがどういうものか分かったうえでレスしてる?



234 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 00:58:26.21 ID:loxtuGTD.net]
>>230
structやenumは単なるtypeだよ
C言語でもstructと(enumの代わりにタグ無しの)unionがあるよね(ただしメソッド定義はできないけど)

235 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:21:04.73 ID:W8ZZnspt.net]
Nim言語にもUFCSがあって関数だけじゃなくtemplateやmacroも関数と同じ

236 名前:文法で呼び出せるのでUFCSが使える。ただし第一引数がuntypedだとmethod call syntaxが使えない。
UFCSのメリットは標準ライブラリとか他人の書いたコードにある型とプロシージャの組に対してもmethod call syntaxが使えることだと思う。
第一引数が組み込み型のプロシージャを定義すれば組み込み型に対してmethod call syntaxが使える。
ライブラリAで定義されている型Xのオブジェクトに対してまったく別に書かれたライブラリBで定義されているgenericsなプロシージャをmethod call syntaxで呼ぶ出すことができる。
[]
[ここ壊れてます]

237 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:28:09.79 ID:5Adpat0k.net]
>>230
structやenum以外でもOK
任意の型にメソッドを定義可能

238 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:31:48.98 ID:W8ZZnspt.net]
>>228
オーバーロードがある言語なら引数が一つ以上あるグローバル関数を追加しても引数さえ異なれば同名の関数をグローバルに追加できる。
UFCSとオーバーロードがある言語では第一引数がFoo型の関数を定義するのはFoo型にメソッドを定義することとほぼ同じとみなせる。

239 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:35:52.92 ID:V8fkjI23.net]
つまりUFCSは汚染でありリスク要因
定義していないメソッドが使えることになってしまう
UFCSがなくとも明確にその型に対して定義されたメソッドのみ対象で実用上困ることはない

240 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:46:11.22 ID:GF+5hMbb.net]
モジュールがあるなら関数のimport有無でどの関数が呼び出されるか制御できたりしないの?
Rustのtraitのuseみたいに

241 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 01:55:33.57 ID:W8ZZnspt.net]
>>235
UFCSのあるNim言語をよく使っているけど特に問題無く使えてるよ。
ライブラリAで定義された型を第一引数に持つ関数をライブラリAの外で定義してもgenerics/template/macroなど使わない限りライブラリAから呼び出せないし、ライブラリA内で使われている関数を外から勝手に上書きできない。
メソッド呼び出ししているように見えてもライブラリA内のプライベートな変数/関数はライブラリの外からアクセスできない。
method call syntaxってa.fooMethod(b)って書いてあるのを
コンパイラがfooMethod(a, b)という関数呼び出しとして解釈しているだけでなんのリスクもないよ。
第一引数にFoo型のオブジェクトをとる関数を定義してもオーバーロードがあるのでFoo型を使わない人には何の影響も与えない

242 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:05:19.36 ID:B7syBDSL.net]
D言語のプロジェクト見て半笑いになるのやめてさしあげろ

243 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:06:16.28 ID:W8ZZnspt.net]
>>236
Nim言語だとimportするときにfrom std/strutils import `%`みたいに特定の型/関数だけをインポートすることができるよ。
もし同じ名前で同じ引数の関数が複数定義されている場合は関数名の前に"モジュルー名."をつけないとコンパイルエラーになる。



244 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:34:25 ID:z8DQnMuR.net]
結局UFCSは不要だよな
メソッド的に使いたいならば最初からその型にメソッドを生やせばよいだけ
必要ならばジェネリックに定義すれば複数の型に同時にメソッドを生やせる
わざわざグローバル関数にしておいてからメソッド的に使えます!とかメリットを一切感じない

245 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 02:47:04 ID:W8ZZnspt.net]
>>240
標準ライブラリにある型とか他人のgithubリポジトリにあるライブラリにも自由にメソッド追加できるの?
ジェネリックにする必要が無いときでもジェネリックにしないとメソッドはやせないの?

Nim言語にはそもそもC++のメンバ関数みたいなのが無くて、第一引数がFoo型の関数がFoo型のメソッドの代わりみたいになっている。

246 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 03:05:01.71 ID:hhhqUz2p.net]
>>241
ジェネリックである必要なし
もちろん同じ機能を複数の型に適用ならジェネリックで1回で済むのが普通

247 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 03:21:57.26 ID:FFLrto9L.net]
>>241
うん
標準ライブラリや第三者ライブラリにある型にもメソッドを増やすことができるよ
だからUFCSが無くても困らないよ

248 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 04:39:58.47 ID:W8ZZnspt.net]
UFCSがあれば引数が一個以上持つ関数であればa.f(b)ともf(a, b)とも書ける。
a.f(b)とf(a, b)の両方で書きたい場合があったらどうするの?
UFCSがなければa.f(b)で呼べるメソッドがあるときジェネリックな関数の中でf(a, b)の形式で呼ばれていたら、わざわざ新しくa.f(b)を中で呼ぶf(a, b)を定義しないといけない。
逆にf(a, b)な関数があったときに新しくメソッドを定義しなくてもa.f(b)と書ける。
それとNimだとcommand invocation syntaxがってf a, bという文法でも関数を呼べる。括弧がないので引数が複雑な式にならなければ書きやすくて読みやすいよ。

249 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 05:29:11.29 ID:d+UJIvmE.net]
>>244
Rustでも可能
例えばu64型のxに対して
xのn乗はu64::pow(x, n)という関数が標準であるけど
これはx.pow(n)と呼び出すことができる

250 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 08:12:23.26 ID:7gaqSdm4.net]
>>225
js/tsなら言語仕様拡張せんでも関数合成だろう。

251 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 08:55:43.85 ID:VjXpH6fC.net]
>>231
>>233
tsではどうやるの?

252 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 11:59:33.54 ID:QEeStXPn.net]
>>241
既存の型にもメソッド追加できるよ
例えばJavaScriptならこんな感じ

// 文字列にhello()を追加
String.prototype.hello = function() {
console.log(`Hello ${this}!`);
};

// 数値にhello()を追加
Number.prototype.hello = function() {
console.log(`Hello ${this}!`);
};

"abc".hello();
// 123.hello(); // 文法エラー
let num = 123;
num.hello();

253 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 12:16:38.60 ID:VSqj5wTk.net]
Rustではジェネリックにメソッド追加することも可能

// メソッドhello()を持つトレイトHelloを宣言
trait Hello {
fn hello(&self);
}

use std::fmt::Display;
// 表示可能トレイトDisplayを満たす全ての型に対してhello()を実装
impl<T: Display> Hello for T {
fn hello(&self) {
println!("Hello {self}!");
}
}

fn main() {
"abc".hello();
123.hello();
}



254 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 12:41:05.03 ID:GF+5hMbb.net]
既存の型へのメソッド追加はプロトタイプ汚染とか言われて忌避されてるよね
他モジュールへの影響の出ない形でメソッド追加する手法が望ましい

255 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 12:53:37.30 ID:BAh3CRfm.net]
>>250
JavaScriptはプロトタイプがグローバルに書き換わり全てのモジュールに適用されるためだな
一方でRustはメソッドを追加するにはトレイトを用意することが必要、そしてトレイトが宣言/useされている空間のみ有効、なので汚染が生じず安全

256 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 13:16:10.20 ID:GF+5hMbb.net]
>>251
型を定義した以外のcrateでメソッドを追加するためにはtraitが必要、が正しいかな
メソッドを追加するためにはtraitなしのimplを書く方法もあるが、これをできるのは型を定義したcrateだけに制限されているので他crateで定義を追加して汚染することはない

とまあRustの事情は知ってるんだけど、他の言語ではどうなってるのかが知りたかった

257 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 13:16:45.41 ID:BiVUGBJZ.net]
知ってるけど今そんな話してるんじゃないんだわ

258 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 13:22:02.11 ID:UiNQmXr4.net]
JavaScriptで脆弱性を生みまくってさんざん問題視されたんだから、いまどきそんな汚染が起こる新しい言語は一つもないよ

259 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 13:30:18.88 ID:5sWL1sIQ.net]
他の言語でもメソッド追加方法を教えて
今のところ
JavaScript >>248
Rust >>249

260 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 13:46:50.81 ID:BiVUGBJZ.net]
発端になったD言語のUFCSハブられてるのなんで?

261 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 13:58:52.24 ID:TLzTt+1G.net]
>>256
UFCSはメリット無いからでしょ
メソッド追加できるなら関数よりメソッドの方が名前空間を汚さないし

262 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 14:21:14.88 ID:UiNQmXr4.net]
>>256
nimには採用されてるし、調べてみるとC++にも導入の提案がされてるみたいだから、それほどハブられてないのでは?

Bjarne Stroustrupの提案: www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4174.pdf
Herb Sutterの提案: https://isocpp.org/files/papers/N4165.pdf

263 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 14:24:50.73 ID:S1pQjSZ5.net]
UFCSはメソッド名空間の汚染
だから採用しないのが正解



264 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 15:13:03.71 ID:B7syBDSL.net]
結局メソッド生やしたいんじゃなくてプライベートメンバにアクセスしたいだけなんだよな

265 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 15:22:37.45 ID:sJr09n4H.net]
>>259
汚染言うならRustのtrailと同レベルじゃない?

関数をincludeしなければ影響無いんだし、言語次第だけど名前空間に閉じ込めることもできるだろ。

266 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 15:28:02.41 ID:VN4zR5UM.net]
>>261
Rustは一切汚染しません
何を誤解しているのですか?

267 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 15:36:09.96 ID:3MmiqOlF.net]
いやトレイトで似たようなメソッドがたくさんぶら下がって汚染されてますよね?それが更にハードルが上がる一因になってる

268 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 15:46:00.36 ID:ZqKc7K5J.net]
>>263
Rustでは明示的にuse Traitしない限り
そのトレイトのメソッドが有効になることはないよ
汚染は起きず安全に設計されている

269 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 15:55:06.48 ID:UiNQmXr4.net]
>>264
当然、D言語でもnimでも、importしたシンボルは、importされたスコープでしか有効にならないし、メソッド形式の呼び出しもできない
Rustと何が違うんだよ

270 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 16:00:14.18 ID:xSu4vg9o.net]
UFCSは強制汚染
関数として必要なだけなのにメソッド名空間を汚染
メソッドとして必要なだけなのに関数名空間を汚染
だから採用する言語がほとんどない

271 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 16:01:50.20 ID:3MmiqOlF.net]
>>264
イヤイヤ、そんなのほとんどの言語でimportやincludeと同じで更に言えば、use std::io::prelude::*;みたいにRustでもPythonでも
誤ったやり方とされてるワイルドカードだって使えるんだから一緒でしょ。明確に言うなら”汚染は起きず”ではなく、汚染は当然ながら
useするのだから起きている。無意味にuseしない*を使わないというのは言語仕様や特性じゃなく規約だよ

272 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 16:08:08.42 ID:UiNQmXr4.net]
スコープやシンボルが限定されてるのに汚染と呼ぶのはおかしい

273 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 16:09:49.70 ID:Ld005CpI.net]
>>267
Rustでは追加メソッドを使う場合
必要な機能のTraitだけを
use TraitName as _; する
そのため汚染は起きない



274 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 16:18:54.63 ID:EM9X2zpO.net]
>>264
ほんとRustニワカ嫌いだわ、「明示的にuse Traitしない限り」なんて良くそんな詭弁が言えるわ。どう考えても一緒でしょう
だからPythonだってas構文使えますし、D言語だってimport std.stdio : writeln, writefln;で選択的インポートできるでしょw

275 名前:デフォルトの名無しさん mailto:sage [2022/04/25(月) 16:21:12.54 ID:PqJDEf6z.net]
Rust聖戦士がワラワラ
他の言語のスタイルはすべてアンチパターン






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<270KB

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