nim

**デフォルトの名無しさん** · 2022/09/11(日) 15:48:12.92

>>178 の例で
var u16 = newSeq[uint16](16)
と定義しておくと(他は変更無し)(後半は0で埋まってる)
ABCDEFG
と表示されます

**デフォルトの名無しさん** · 2022/09/11(日) 15:48:57.35

まあ cast に何を期待してるんだと言われればそれまでなんだと思いますが腑に落ちませんでした

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

nimってIDEやデバッガは近いうちに計画されてるの？
vscodeでもいいんだけど、ちゃんとしたデバッガは欲しいな
条件付きブレークポイントやコンテナの中身が見れる程度でいいんだが

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

>>182

vscodeのプラグイン
nimsaem.nimvscode + webfreak.debug ではだめか？

**デフォルトの名無しさん** · 2022/09/11(日) 22:55:03.70

やっぱりその組み合わせか
どうにも使いづらいんだよねぇ
言語仕様は理想に近いんでもっと流行ってほしいんだが、これまでの情勢からあまり期待できなさそうだな

**デフォルトの名無しさん** · 2022/09/12(月) 01:44:56.16

>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcast

**デフォルトの名無しさん** · 2022/09/12(月) 01:47:29.58

>>181
seqをstringにcastしているけど、ちゃんとseqとstringの実装詳細、データ構造を理解した上で安全だという確証があってcastしてるの？
そうでないならcast使うのはやめたほうがいいよ。

**デフォルトの名無しさん** · 2022/09/12(月) 02:10:20.86

>>181
seqやstringのデータ構造を理解しcastが何をしているか理解すれば納得できると思うよ
https://github.com/nim-lang/Nim/blob/devel/lib/system/seqs_v2.nim
https://github.com/nim-lang/Nim/blob/devel/lib/system/strs_v2.nim
そもそもseq[uint16]からstringへcastしてる時点でもうデタラメなんだよ。

**デフォルトの名無しさん** · 2022/09/12(月) 02:17:45.60

>>182
NimにGDBでデバッグできるようにするプラグインが付属していて
gdbでブレークポイントをおいたり変数の中身を表示したりできます。
https://internet-of-tomohiro.netlify.app/nim/gdb.ja.html

**デフォルトの名無しさん** · 2022/09/12(月) 20:00:29.06

>>178 >>180
var u16 = newString(16)
for n in 0..7: u16[n * 2] = cast[char](65 + n); u16[n * 2 + 1] = '\0'
u16[14] = '\0'
echo u16 # -> A B C D E F G
echo convert(u16, "utf-8", "utf-16") # -> ABCDEFG

**デフォルトの名無しさん** · 2022/09/12(月) 22:26:15.30

>>189
castは極力使わないほうがいいのでビット演算使ってu16の値をcharに変換したほうがいいよ。
お手本コードを投稿しようとしたらcloudflareが悪意あるコードと勘違いしてブロックされた

**デフォルトの名無しさん** · 2022/09/12(月) 22:30:11.19

こんな感じです
ｌeｔｃ=６５u１６ + n
u１６[n * ２] = ｃｈar(ｃ and 0xｆｆ'u１６)
u１６[n * ２ + 1] = ｃｈar(ｃ shr ８)

**デフォルトの名無しさん** · 2022/09/13(火) 11:55:15.89

>>176
これ観ろ
https://khchen.github.io/winim/winstr.html

**デフォルトの名無しさん** · 2022/09/13(火) 12:06:13.19

言語仕様としてはモダンな言語の中で1番わかりやすいし
Rustで書くほどでもない軽いスクリプトとかならNimで良いんだけど流行らんなあ
やはり個人開発者の言語が流行ることはもうないのか

**デフォルトの名無しさん** · 2022/09/13(火) 15:06:32.01

>>189 >>192
ありがとうございました

**デフォルトの名無しさん** · 2022/09/13(火) 16:00:02.06

アク禁？

**デフォルトの名無しさん** · 2022/09/13(火) 16:03:11.36

var ws = newWideCString(8) # ws.len == 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
# ws.len == 8
ws[7] = Utf16Char(0) # ws.len == 7
echo ws # ABCDEFG
と比べて

**デフォルトの名無しさん** · 2022/09/13(火) 16:05:36.05

なぜ拒否られる？

**デフォルトの名無しさん** · 2022/09/13(火) 16:06:26.54

驚き最小の法則ですね
var s = newString(8) # s.len == 8
for n in 0..7: s[n] = ｃｈａｒ(65 + n)
# s.len == 8
s[7] = '\0' # s.len == 8
echo s # ABCDEFG

**デフォルトの名無しさん** · 2022/09/13(火) 16:07:15.32

判ったｃｈａｒだけダメなんね

**デフォルトの名無しさん** · 2022/09/13(火) 16:09:20.44

驚き最小の法則
var ws = newWideCString(8)
echo ws.len # -> 0
for n in 0..7: ws[n] = Utf16Char(65 + n)
echo ws.len # -> 8
ws[7] = Utf16Char(0)
echo ws.len # -> 7
echo ws # ABCDEFG
と比べて
var s = newString(8)
echo s.len # -> 8
for n in 0..7: s[n] = ｃｈａｒ(65 + n)
echo s.len # -> 8
s[7] = '\0'
echo s.len # -> 8
echo s # ABCDEFG

**デフォルトの名無しさん** · 2022/09/13(火) 16:11:32.87

インド人もびっくり

**デフォルトの名無しさん** · 2022/09/13(火) 19:05:39.59

Win土人
Nim土人

**デフォルトの名無しさん** · 2022/09/16(金) 10:37:25.88

proc testfunc(x: cint): cint {.exportc, cdecl, dynlib.} =
return x
と描かれたソースを
nim c --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されて
import ctypes
ctypes.cdll.LoadLibrary('./hoge.dll').testfunc(123)
と実行出来たのですが
nim cpp --app:lib -d:release hoge.nim
でコンパイルするとカレントディレクトリに hoge.dll が生成されているはずなのに
LoadLibrary のところで
FileNotFoundError: Could not find module '(fullpath)\hoge.dll' (or one of its dependencies).
Try using the full path with constructor syntax.
と言われてしまいます
多分 or one of its dependencies が引っ掛かっているのではないかと思うのですが
何が足りないのでしょう？ stdc++ の shared library ?

**デフォルトの名無しさん** · 2022/09/16(金) 10:57:11.84

libstdc++-6.dll
をコピーしてみましたがだめでした

**デフォルトの名無しさん** · 2022/09/16(金) 11:30:30.18

nimpy
nimodule

**デフォルトの名無しさん** · 2022/09/16(金) 13:53:03.44

>>203
objdumpっていうプログラムを使えばどのdllを使っているか見れるよ。
使い方忘れたからググってね。
Nimをインストールしたときにgccもインストールしてればそのときにobjdumpも一緒にインストールされる。
他にも依存しているdllを見れるツールは色々あるけど

**デフォルトの名無しさん** · 2022/09/16(金) 16:11:50.14

>>206
windows用にもobjdumpあんの？

**デフォルトの名無しさん** · 2022/09/16(金) 16:24:53.42

windows で nim 入れるときに一緒に入った mingw64 の中に objdump がありました

**デフォルトの名無しさん** · 2022/09/16(金) 16:34:58.81

>>206
objdump -p hoge.dll | findstr "dll"
で出て来たのが
libgcc_s_seh-1.dll
libstdc++-6.dll
kernel32.dll
msvcrt.dll
でした
libstdc++-6.dll
だけではなく
libgcc_s_seh-1.dll
も必要でした
無事動作しましたありがとう

**デフォルトの名無しさん** · 2022/09/18(日) 09:51:11.78

>>200
https://github.com/tauplus/nim_doc_ja/blob/master/nim-meory_ja.md#%E6%96%87%E5%AD%97%E5%88%97%E3%81%A8%E3%82%B7%E3%83%BC%E3%82%B1%E3%83%B3%E3%82%B9Strings-and-seqs

**デフォルトの名無しさん** · 2022/09/22(木) 10:36:47.71

import nimpy
import nimpy/py_lib as lib
initPyLibIfNeeded()
let wx = pyImport("wx")
let app = wx.App()
let frm = wx.Frame(nil, -1, "Hello, work!")
discard frm.Show()
discard app.MainLoop()

簡単杉感嘆

**デフォルトの名無しさん** · 2022/09/22(木) 15:46:35.23

こんなのや
https://github.com/khchen/wNim
こんなのも
https://github.com/simonkrauter/NiGui

**デフォルトの名無しさん** · 2022/09/23(金) 15:49:32.66

セルフホスティングくらいでけるのか？

**デフォルトの名無しさん** · 2022/09/23(金) 16:54:42.46

>>213
セルフホストってどういう意味で言ってるかは知らないけど
Nim forum自体がNimで実装されてるよ。
https://github.com/nim-lang/nimforum

**デフォルトの名無しさん** · 2022/09/23(金) 20:37:31.28

プログラミング言語でセルフホスティングっていったらコンパイラが自身の言語で実装できることだろうよ
しかしできたとしてトランスパイラをセルフホスティングと呼んでいいのか

**デフォルトの名無しさん** · 2022/09/23(金) 22:00:58.25

出力がC言語か機械語かの違いぐらいだしトランスパイラだとしても普通にセルフホスティングって呼ぶよ

**デフォルトの名無しさん** · 2022/09/23(金) 22:27:48.78

https://github.com/nim-lang/Nim
ここにNim言語のコンパイラがあるけどソースコードはNim言語で書かれている。
gccなどのCコンパイラとgitがあればソースコードからビルドできる。
ソースコードからビルドするときはまず古いバージョンのNimコンパイラをC言語に変換したものをダウンロードしてCコンパイラでビルドする。
それでビルドしたNimコンパイラで最新のNimコンパイラをビルドする。

**デフォルトの名無しさん** · 2022/09/24(土) 20:13:52.60

わりとどうでもいいな

**デフォルトの名無しさん** · 2022/09/25(日) 02:56:32.67

Cコンパイラは一般的にC言語で実装されているが、どうやってCコンパイラをビルドするのか
あらかじめビルド済みのCコンパイラを持ってきてビルドする
ではそのビルド済みのCコンパイラはどうやってビルドされたというのか

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

たぶん世界で最初のC言語はアセンブリかB言語かフォートランか何か別の言語で書かれていたんじゃないの?

**デフォルトの名無しさん** · 2022/09/26(月) 14:35:28.98

BigBangは未だ仮説だ

**デフォルトの名無しさん** · 2022/09/28(水) 12:46:44.72

toSeq(0..360|24).map(rad)
と描くと
Error: type mismatch: got <SteppedSlice>
と言われて怒られたので
toSeq(0..360).filter(x => x mod 24 == 0).map(rad)
で描き治したら一応動く訳だが
0..360|24
観たいに描く方法は？

**デフォルトの名無しさん** · 2022/09/28(水) 13:40:07.41

iterator `|`(x: HSlice; y: int): int =
みたいな演算子のイテレータを定義すればいいじゃん。

**デフォルトの名無しさん** · 2022/09/28(水) 17:12:46.81

nim 1.6.8 出た

**デフォルトの名無しさん** · 2022/09/29(木) 21:45:04.30

ウィ

**デフォルトの名無しさん** · 2022/10/02(日) 11:50:55.49

>>223
iterator items(s: SteppedSlice): int =
var c = s.a
while c <= s.b:
yield c
c += s.step

を定義したらイケました
有賀豚

**デフォルトの名無しさん** · 2022/10/16(日) 04:20:39.65

ニンニン

**デフォルトの名無しさん** · 2022/10/22(土) 14:42:48.48

本日のNimConf2022期待age

**デフォルトの名無しさん** · 2022/11/02(水) 12:51:11.01

1，2ヶ月くらい前に
Nim言語のマニュアル日本語訳がOSDNのページにアップされていて
これで5年後には結構人気が出るかもと喜んでいたら
突然ページが消滅してショックだった

キャッシュを探したけど発見できないので
コピー持ってる人がいたらどこかにアップしてもらえらばありがたいです
(ライセンス上問題が無ければですが)

**デフォルトの名無しさん** · 2022/11/02(水) 22:26:34.03

古いキャッシュならInternet Archiveにあった
https://web.archive.org/web/20201128232605/http://nim-lang-081.osdn.jp/
https://web.archive.org/web/20200928154858/http://nim-lang-081.osdn.jp/docs/manual.html

まあキャッシュ古すぎて更新追いついてないけど

**デフォルトの名無しさん** · 2022/11/02(水) 22:33:40.08

https://ja.osdn.net/users/megumi_engines/projects/
このひとがオーナーになってるプロジェクトの1つみたいだけど、Twitterのアカウントも消えちゃってるね
プライベートが忙しくなったのかな

**デフォルトの名無しさん** · 2022/11/03(木) 15:08:48.38

Last Update: 2022-09-21 01:12
Nim プログラミング言語 - 非公式日本語版 (翻訳活動終了)に関する活動はすべて終了しました。リポジトリの再公開予定はありません。

理由はよう判らん
githubにfork無かったかな

**デフォルトの名無しさん** · 2022/11/04(金) 07:27:29.10

日本語訳マニュアルの代わりになるかどうかはわからんけど
amazonで日本語のNim言語の書籍が売られてるよ。

**デフォルトの名無しさん** · 2022/11/05(土) 00:35:21.38

当時高校生の描いたやつか
CやC++との連携について
一行しか描かれてなかったな

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

c2nim にがっかり感なんだけど
こんなもん？
それとも使い方間違ってる？
期待し過ぎ？

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

単純化した具体例がないとなんとも

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

わかっているのかもしれないけど、c2nimはどんなC言語のコードもNim言語に変換するものではない。C言語ライブラリをNim言語から使うためのバインディングをCのヘッダーファイルから生成するツールみたいなものだ。
c2nimに似たことができるこんなツールもあるよ。
https://github.com/PMunch/futhark

**デフォルトの名無しさん** · 2022/11/07(月) 12:40:52.04

>>230
全く使えないキャッシュだな

**デフォルトの名無しさん** · 2022/11/07(月) 12:44:41.58

>>229
3年前の nim 1.4.0だけど Nim日本語マニュアル
https://github.com/tauplus/nim_doc_ja

**デフォルトの名無しさん** · 2022/11/07(月) 13:21:56.37

ダメだこりゃ
みんなでzigに移動しよう

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

いーんだよ　グリーンだよ

**デフォルトの名無しさん** · 2022/11/08(火) 12:57:20.87

template hoge(fuga: string): string =
fmt"{fuga}"

観たいなときに fuga が undeclared になるんだけどなんで？

**デフォルトの名無しさん** · 2022/11/08(火) 13:05:00.14

>>237
なるほど良さげ

Sounds great, what's the catch?
Futhark is currently in an alpha state.
It currently doesn't support C++, and it doesn't understand things like function-style macros.
It might also mess up on definition types I haven't seen yet in the small handful of libraries I've tested it against.
All of these things are things I hope to get fixed up.

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

>>242 自己レス
出来ました本当にありがとうございました
template hoge(fuga: string): string =
block:
let injectedfuga {.inject.} = fuga
fmt"{injected_fuga}"
https://qiita.com/momeemt/items/000d1f6c384f4f00e103

**デフォルトの名無しさん** · 2022/11/08(火) 18:53:20.46

>>244
それは公式ドキュメントのここに書いてあるじゃないですか。
https://nim-lang.org/docs/strformat.html#limitations

**デフォルトの名無しさん** · 2022/11/08(火) 19:07:14.22

Pythonスレでテンプレになってる内容をNim用に変更したので
次スレからはテンプレにしてください

-----ここから

Nimの★ソースコードをそのまま５ちゃんに貼るとインデントが崩れてチヌ★
【【【複数の連続半角スペースはなにもなかったことにされる＆タブは普通には入れられない】】】掲示板の仕様なので、
プログラム文は↓等の、いわゆるコードうｐ用サイトに貼ってこいください。
ttps://glot.io/new/nim　　　　結構使える。
ttps://play.nim-lang.org/　　　本家。
ttp://ideone.com/　　　　　　デフォ設定はC用のため、言語選択ボタン押下がﾋﾟｺ手間かも。
ttp://pastebin.com/　　　　　まずまずシンプル。

-----ここまで

**デフォルトの名無しさん** · 2022/11/09(水) 22:27:24.03

判り初めた my Revolution

**デフォルトの名無しさん** · 2022/11/10(木) 13:14:50.85

試してみた
本家 https://play.nim-lang.org/#ix=4ftO
スッキリ https://glot.io/snippets/gf9x33imvc
ダメぽよ(実行時エラー？) https://ideone.com/9BYjHA (たまに死ぬよねこのサイト)
貼るだけ？ https://pastebin.com/07h9Zjrx

ideoneがダメなのはバージョンの問題？

**デフォルトの名無しさん** · 2022/11/10(木) 13:25:08.92

これで逝けました
https://ideone.com/HBEKZu
pragmaのNimNodeを指定出来なかったらしい
ideone の Nim は (nim 0.19.4)

**デフォルトの名無しさん** · 2022/11/10(木) 14:16:57.58

https://wandbox.org/

**デフォルトの名無しさん** · 2022/11/10(木) 15:04:27.30

↑のWandboxでも最新の安定版Nimを使えるしコードを共有できる。

**デフォルトの名無しさん** · 2022/11/10(木) 15:55:36.21

ここまでのまとめ
ttps://glot.io/new/nim　　　　結構使える
ttps://wandbox.org/ 最新のNim使える
ttps://play.nim-lang.org/　　本家
ttp://pastebin.com/　　　　　ソース貼り付けのみ

**デフォルトの名無しさん** · 2022/11/10(木) 16:23:45.65

やっぱオフサイドスタイルはクソかよ。

**デフォルトの名無しさん** · 2022/11/10(木) 16:52:41.86

>>250
wandboxだと(っていうかそれ以外でもかもだけど)
実行ボタンの上に
$ nim c ./prog.nim
って表示されてて c を cpp に変更したくても出来ない
左上の「コンパイルオプション」らしい枠に cpp を入れると
$ nim c ./prog.nim cpp
になったわ

**デフォルトの名無しさん** · 2022/11/10(木) 20:00:36.53

>>254
確かにwandboxだとnim cppでコンパイルできないっぽいね
もしかしたらgithubのwandboxリポジトリに要望を出せば対応してくれるかもしれない。もしくは自分で機能を実装してpull requestを出すか

**デフォルトの名無しさん** · 2022/11/11(金) 10:16:18.33

ここは未完成なのかな
日本語マニュアルっぽいけど
https://2vg.github.io/Nim-World/

**デフォルトの名無しさん** · 2022/11/12(土) 14:40:51.16

自分で育てる感覚楽しいですね

**デフォルトの名無しさん** · 2022/11/15(火) 13:26:12.68

type
Hoge* = object
fuga*: int
としないで
type
HogeObj* = object
fuga*: int
Hoge* = ref HogeObj
とするのは必須？習慣？
前者のデメリットは DeepCopy だというのは判るのですが
毎回後者を使った方が良い？

**デフォルトの名無しさん** · 2022/11/16(水) 09:07:52.80

{.byref.} じゃね？

**sage** · 2022/11/16(水) 13:30:51.35

横からだが
>>259 のbyrefと >>258 は完全に等価？

**デフォルトの名無しさん** · 2022/11/16(水) 15:57:06.50

proc 読んだとき ref のフリをする fake が 259

**デフォルトの名無しさん** · 2022/11/16(水) 18:16:18.08

ref objectは一つのオブジェクトを複数のオブジェクトから参照したいときや継承使ってオブジェクト指向なコードを書くときに必要となる。
それ以外の場合はrefのついていないobjectのほうが速くなることが多い。
ref型は常にヒープに確保されポインタ経由でアクセスされるけどobjectだとスタックに確保できるしポインタで間接的に参照する必要もない。
object型のseqだとメモリ上に連続して確保されるけどref object型のseqにするとメモリ上に連続して確保されるとは限らないからキャッシュミスが起きやすくなる。
ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるからコピーのコストが問題になることがあんまりないと思うよ。
C++で言えばobjectはstructをそのまま使っている感じでref objectはstructをstd::shared_ptrごしに使っている感じ。

**デフォルトの名無しさん** · 2022/11/17(木) 09:41:27.60

proc incx(i: int): int =
let j = i
{.emit: "++j;".}
result = j

echo incx(5)

https://glot.io/snippets/gfgq0p65a6
let で定義された変数も書き換え可能なんですね素敵ですね

**デフォルトの名無しさん** · 2022/11/17(木) 09:41:55.68

>>259-260
全く別物

**デフォルトの名無しさん** · 2022/11/17(木) 09:45:16.34

>それ以外の場合はrefのついていないobjectのほうが速くなることが多い。

これはどうかなぁ
遅くなることの方が多いと思うが

**デフォルトの名無しさん** · 2022/11/17(木) 10:53:32.89

>>265
どうしてrefのついてないobjectのほうが遅くなる場合が多いの?

**デフォルトの名無しさん** · 2022/11/17(木) 14:28:18.19

>>263
emit pragma使っているんだからNimの安全性は無効になる。
rustでunsafeを使うようなもの。

**デフォルトの名無しさん** · 2022/11/17(木) 15:18:49.83

>>262
>ある程度大きなobjectはプロシージャに渡すときに自動的にポインタ経由で渡されるから

ってことは {.byref.} 描く必要無い？

**デフォルトの名無しさん** · 2022/11/17(木) 17:33:28.89

>>268
自動でやるのは関数の引数にオブジェとを渡した時だから
それ以外にコピーが頻繁に発生しないなら
byrefいらないんじゃね?

**デフォルトの名無しさん** · 2022/11/17(木) 18:51:38.00

>>268
https://nim-lang.org/docs/manual.html#procedures-var-parameters
に
var parameters are never necessary for efficient parameter passing. Since non-var parameters cannot be modified the compiler is always free to pass arguments by reference if it considers it can speed up execution.
って書いてあります。

**デフォルトの名無しさん** · 2022/11/17(木) 19:03:15.70

>>268
https://nim-lang.org/docs/manual.html#foreign-function-interface-byref-pragma

Nim manualではbyref pragmaがForeign function interfaceの章の下にある。
つまりbyref pragmaはC/C++の関数に引数をポインタ渡ししなきゃいけないときに使うもの。
それ以外のときに使う必要性はほぼ無いってこと。

**デフォルトの名無しさん** · 2022/11/17(木) 21:39:23.14

>>265
そんな速度差気付くことある？

**デフォルトの名無しさん** · 2022/11/18(金) 05:58:57.10

君らスタックの消費は気にならんのけ？

**デフォルトの名無しさん** · 2022/11/18(金) 06:16:37.43

>>273
10kバイト以上のでかいobjectをたくさん使うとかならスタックを使わないようにref objectにしてヒープに確保してもいいと思う。
けどそんなにでかいobject型のローカル変数をたくさん使うことってあんまりないきがするけど。

**デフォルトの名無しさん** · 2022/11/18(金) 09:39:59.23

たとえば
https://qiita.com/dumblepy/items/8d13592d6760d0155d89
>オブジェクトの宣言にはref objectを使います。
>Nimでは関数の引数に入れられた変数の容量に応じてコンパイラが自動で値渡し/参照渡しを調節しますが、
>これは挙動の予測が付かずバグの原因になりえます。
>ref objectでオブジェクトを宣言していれば必ず参照渡しになるので、
>アプリケーション開発ではこちらに統一しましょう。

みたいなことが

**デフォルトの名無しさん** · 2022/11/18(金) 10:17:44.40

問題無い訳ではないとも
https://flat-leon.はてぶろ.com/entry/nim_arg_pass
バージョンや記事の年代に気を付けないといかんのかね

**デフォルトの名無しさん** · 2022/11/18(金) 11:42:20.25

古いけどここの議論は判り易い
https://forum.nim-lang.org/t/1207

**デフォルトの名無しさん** · 2022/11/18(金) 11:48:22.19

>>270
それは var の説明であって ref の説明ではないですね

**デフォルトの名無しさん** · 2022/11/18(金) 12:02:19.50

>>275
>>278
refのついた型またはvar引数は常に引数を参照渡し(ポインタのコピー)する。
refやvarがついてない場合は引数のサイズにあわせてコピー渡しか参照渡しになるが、どちらにせよプロシージャ内で引数を変更するのは禁止

**デフォルトの名無しさん** · 2022/11/18(金) 12:10:00.28

だからデフォルトの引数の渡し方でそれがコピー渡しになろうが参照渡しになろうがそれで挙動が変わったりバグの温床になることはない。
ただしaddrとかemit, Assembler statementなどのNimが安全性を保証してない機能を使う場合は例外だ。

**デフォルトの名無しさん** · 2022/11/18(金) 12:24:09.04

参照とか reference とか同じ名前だから混同してるのかも知れないが
Nim の参照型と C++ の参照型は全く別物
C++ の引数で使う参照型 & は Nim では var の方が近い
Nim の ref は C++ ではポインタ * と思った方が良い
Nim では
GC で管理されるポインタが ref
GC で管理されないポインタが ptr

**デフォルトの名無しさん** · 2022/11/18(金) 17:46:16.11

これ使うか使わないかでも全然違うのよね --gc:arc

**デフォルトの名無しさん** · 2022/11/18(金) 18:35:09.65

最近は --mm:arc

**デフォルトの名無しさん** · 2022/11/19(土) 16:28:59.40

--mm:orc 推奨

**デフォルトの名無しさん** · 2022/11/19(土) 17:55:05.22

Nim2では--mm:orcがデフォルトになるらしいぞ。
みんな知ってると思うけど--mm:arcだともし循環参照があったときにメモリリークするぞ。

**デフォルトの名無しさん** · 2022/11/19(土) 19:05:39.54

Nim2なんて10年以上先

**デフォルトの名無しさん** · 2022/11/20(日) 10:26:07.81

>>275 のリンク先なんか
「Nimでアプリケーション開発をするための設計のベストプラクティス」
みたいにイキってるけど
信用していいの？

**デフォルトの名無しさん** · 2022/11/20(日) 11:36:46.79

object type 全部 ref 付けろ教のひと
たまにいるよね
迷惑

**デフォルトの名無しさん** · 2022/11/21(月) 13:35:10.22

割と実用になるわね
https://pastebin.com/Ry2wTRHi

**デフォルトの名無しさん** · 2022/11/22(火) 09:38:49.09

理由を示さないお作法は無視していい

**デフォルトの名無しさん** · 2022/11/24(木) 09:24:22.39

なんでもかんでもref付けろと
しつこく強要してる人は
あたまおかしい
大抵は{.byref.}で用足りる

**デフォルトの名無しさん** · 2022/11/24(木) 15:02:15.10

{.byref.}はnimからC/C++の関数を使うときに引数をポインタで渡しているときに使うもの。
それ以外では使う意味はないよ。
Nimはちゃんと最適な方法で引数を渡すから必要でもないのに{.byref.}とかvarとかつける必要はない。

**デフォルトの名無しさん** · 2022/11/24(木) 18:37:53.45

var も ref も byref も全部別物だと何度言えば判るんだ？

**デフォルトの名無しさん** · 2022/11/24(木) 18:42:50.52

>>293
みんなが必ず遭遇する問題なので
短くまとめて次スレからテンプレにするのが良い
以下 >>293 のテンプレが続く

**デフォルトの名無しさん** · 2022/11/25(金) 09:06:20.12

{.byref.}をrefと間違うのは判らんでもないし同情するが
{.byref.}をvarと間違う香具師は初めて観た

**デフォルトの名無しさん** · 2022/11/25(金) 16:53:59.56

nim 1.6.10 出た

1.6.98 まで行くのかw

**デフォルトの名無しさん** · 2022/11/27(日) 12:26:56.31

regexどれ使えば良いの？

**デフォルトの名無しさん** · 2022/11/27(日) 16:05:43.13

>>297
好きなのでいいんじゃ ?

**デフォルトの名無しさん** · 2022/11/27(日) 17:37:23.28

>>297
Nimでは正規表現よりPEGのほうがおすすめらしい。
https://nim-lang.org/docs/pegs.html

PEG (Parsing expression grammar) is a simple deterministic grammar, that can be directly used for parsing. The current implementation has been designed as a more powerful replacement for regular expressions. UTF-8 is supported.

**デフォルトの名無しさん** · 2022/11/28(月) 05:25:04.28

300

**デフォルトの名無しさん** · 2022/11/29(火) 12:04:17.71

pythonのStringIOとかBytesIOみたいなのは無い？

**デフォルトの名無しさん** · 2022/11/29(火) 14:03:26.53

>>301
FileStreamとStringStream かも
https://nim-lang.org/docs/streams.html

**デフォルトの名無しさん** · 2022/12/02(金) 09:32:24.76

https://nim-lang.org/docs/streams.html を観ると
FileStream = ref FileStreamObj ← 判る
FileStreamObj = object of Stream ← 判らん
StringStream = ref StringStreamObj ← 判る
StringStreamObj = object of StreamObj ← 判る
Stream = ref StreamObj ← 判る
StreamObj = object of RootObj ← 判る

なんで
FileStreamObj = object of StreamObj
になっていないのでしょう？
意図を知りたいです

**デフォルトの名無しさん** · 2022/12/02(金) 09:38:11.16

https://github.com/nim-lang/Nim で
lib/pure/streams.nim の type を観ても
FileStream のだけ
FileStream* = ref FileStreamObj
FileStreamObj* = object of Stream
でした

**デフォルトの名無しさん** · 2022/12/02(金) 17:15:15.76

命名の推測で「WHY？」という話なら、ofキーワードの後に来るのが、必ずxxxObjという規約ではないから。

目的としてxxxObjでないのは、それを扱いやすくするためでStringStreamやStreamはそのまま宣言したり
引数に渡したり、戻り値の型として記述して使用するのに対してxxxObjは普通にライブラリの使用者は
めったに直接的に使用しない。（ライブラリの設計者・実装者は普通に使う）
例を言えば、MemMapFileStream、ReadSocketStreamなども利用者は直接的に使用するが、いずれも
ストリーム系だがobject of の後にくるものは違う。

例えば、利用者はプロセスの出力をStreamで使用するなら、このようなprocを使う
proc outputStream*(p: Process): Stream

これを、クライアントプログラムの実装者が受け取る変数の定義でStreamObjと書いていたらおかしい。
APIドキュメントには、「最も使用される一般名称にはそのままの名前を付ける」としか書いてないが
Nimに限らず一般的に、１つか少数の抽象名と数多くの具象名は一般名称でプレ・サフィックスは付けない
https://nim-lang.org/docs/nep1.html
When naming types that come in value, pointer, and reference varieties, use a regular name for the variety that is to be used the most, and add a "Obj", "Ref", or "Ptr" suffix for the other varieties. If there is no single variety that will be used the most, add the suffixes to the pointer variants only. The same applies to C/C++ wrappers.

似た話にxxxRefがあるがこちらはref objectに単に付けるが、型名をあまり使用しない場合で、なおかつ
ref objectであることを強調する場合が多い。
StringTabeRef* = ref StringTabeObj
var tbl = newStringTable(...)

**デフォルトの名無しさん** · 2022/12/02(金) 18:20:09.03

https://play.nim-lang.org/#ix=4hrl
継承するときに基の型についてるrefは無視されるようなので
objectかref objectのどちらから継承しているかは重要ではないようだ。

**デフォルトの名無しさん** · 2022/12/03(土) 14:54:39.83

>>306
なるほど！

**デフォルトの名無しさん** · 2022/12/08(木) 15:32:48.39

template とか macro とか使うと
流れる様にさらさら描けて気持ち良いわコレ

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

templateとmacroを上手くに使えるようになりてえなあ☹

**デフォルトの名無しさん** · 2022/12/13(火) 09:48:40.02

こんな感じのmacroを書いていろんなコードを与えてみよう。
コンパイル時にecho x.treeReprの出力が表示される。
それを読めばNimのコードはAST(抽象構文木)になることが理解できると思う。
これがNimのmacroを理解する第一歩だと思う。

import std/macros

macro test(x: untyped): untyped =
　echo x.treeRepr

test:
　echo "test"

後はこれを読めばok
https://nim-lang.org/docs/manual.html#macros
https://nim-lang.org/docs/macros.html

**デフォルトの名無しさん** · 2022/12/14(水) 10:22:41.84

macro は AST 知ってると有利だね
あと head と body を受け取るタイプのと
node を受け取るのと
static type を受け取るのとか
区別して理解しないと
自分が何やってるのか判らなくなる

**デフォルトの名無しさん** · 2022/12/14(水) 15:44:32.71

へぇ、それはクソ仕様だね

**デフォルトの名無しさん** · 2022/12/14(水) 21:28:27.69

node造る関数も直交性が無いな

**デフォルトの名無しさん** · 2022/12/17(土) 10:10:45.75

直交性という言葉を知ってるオジサン・・・
C/C++言語の#def, #include→別言語（直交性100%)、錆びのprintln!→実は別言語（直交性100%)
むしろこれは言語が習得で異なる仕様の言語を2つ覚えないといけない、敷居を高くする欠点

**デフォルトの名無しさん** · 2022/12/17(土) 10:46:30.65

NimNodeはseqに近い方法で扱えるようにmacrosモジュールにプロシージャが定義されているのはいいことでは。

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

untyped は obsoleted

**デフォルトの名無しさん** · 2022/12/17(土) 18:07:52.62

今はNimNodeじゃなく、quote do:で書くのが良いよな。どうしてもNimNodeじゃなきゃ書けないマクロもあるだろうけどね

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

>>317
https://nim-lang.org/docs/genasts.html
https://github.com/nim-lang/Nim/pull/17426
https://github.com/nim-lang/RFCs/issues/122

**デフォルトの名無しさん** · 2022/12/22(木) 07:38:06.92

最初のrelease candidate for Nim v2.0が公開されました。
https://nim-lang.org/blog/2022/12/21/version-20-rc.html

**デフォルトの名無しさん** · 2022/12/22(木) 10:51:20.76

ペース早いよなあ

**デフォルトの名無しさん** · 2022/12/22(木) 10:52:43.57

nim-2.0 RC1 がリリースされた
https://nim-lang.org/blog/2022/12/21/version-20-rc.html

来年1月か2月には正式2.0になるのかも

**デフォルトの名無しさん** · 2022/12/23(金) 02:05:06.61

もう2.0かよ(´・ω・`)公開してるライブラリ大丈夫かな

**デフォルトの名無しさん** · 2022/12/23(金) 20:17:33.78

バージョンが大きく変わって大丈夫と思う方が
無理がある

**デフォルトの名無しさん** · 2023/01/16(月) 16:24:59.02

あっという間に2月

**デフォルトの名無しさん** · 2023/01/23(月) 22:52:56.91

書き込みが1ヶ月に1回しかないスレ w

**デフォルトの名無しさん** · 2023/01/26(木) 03:28:17.45

Nim言語を使っていても特につまづくことがないから話題があんまりないんだよね。

**デフォルトの名無しさん** · 2023/01/26(木) 18:39:32.28

使用者の絶対数が少なすぎ

**デフォルトの名無しさん** · 2023/02/01(水) 01:23:34.72

てすと

【だん吉】 · 2023/03/01(水) 09:22:10.73

!omikuji

**デフォルトの名無しさん** · 2023/03/01(水) 12:20:14.81

初心者はys3mとかrs3mで十分

Ziicubeでys3m出た
1割引き価格後の値段

679円マグネット
1151円 Maglev
1623円 Boall-Core

https://www.ziicube.com/Moyu-333-HuaMeng-YS3M

**デフォルトの名無しさん** · 2023/03/01(水) 12:20:39.02

>>330
誤爆

**デフォルトの名無しさん** · 2023/03/05(日) 11:11:16.11

WinnyとNimってネーミングセンス似てるね

**デフォルトの名無しさん** · 2023/03/05(日) 19:55:40.66

>>332
Nimは元々Nimrodっていう名前だったんだけどその由来は
https://forum.nim-lang.org/t/9591#63054

**デフォルトの名無しさん** · 2023/03/06(月) 14:19:57.93

https://www.cosme.net/product/product_id/10190076/top

**デフォルトの名無しさん** · 2023/04/03(月) 17:59:13.21

この言語ってRustみたいにプログラマに押し付けるmutなんて使ってないのに、なんでいわゆるMove操作が勝手に出来るの？
説明しろください！

**デフォルトの名無しさん** · 2023/04/03(月) 18:32:57.47

>>335
こちらの資料には目をとおされましたか？
https://nim-lang.org/docs/destructors.html

**デフォルトの名無しさん** · 2023/04/09(日) 09:29:43.33

Nim良いよね
Rustは宣伝がうざいだけだが
Nimは判ってる人の間でまったり進化してくれ

**デフォルトの名無しさん** · 2023/05/04(木) 21:15:01.62

公式読めばだいたいのことはわかるから特にここでも議論は出ないよね
唯一日本語の書籍がもう一冊くらい欲しいなあくらい

**デフォルトの名無しさん** · 2023/05/06(土) 09:24:18.50

importとincludeの違いってなに？

**デフォルトの名無しさん** · 2023/05/07(日) 06:11:02.39

>>339
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#import-statement
https://qiita.com/tauplus/items/80afbd47f3a44158ea1f#include-statement

**デフォルトの名無しさん** · 2023/06/28(水) 19:11:48.73

Nim言語 1.6.14 リリｰス
https://nim-lang.org/blog/2023/06/27/version-1614-released.html

**デフォルトの名無しさん** · 2023/07/02(日) 18:18:52.72

夜遅くにすいません。
SyntaxHilighter用のNim Brushってどっかにありませんか？

**デフォルトの名無しさん** · 2023/07/02(日) 18:34:57.51

>>342
話の内容が全然理解できないけど。。。

**デフォルトの名無しさん** · 2023/07/02(日) 21:16:17.65

>>343
ごめんなさい。
SyntaxHighlighter でした。

**デフォルトの名無しさん** · 2023/07/02(日) 21:56:05.97

>>344
SyntaxHighlighter っていうのがよくわからないけど
VSCode拡張とかのこと?

**デフォルトの名無しさん** · 2023/07/03(月) 07:33:58.97

>>345
えぇｴ～それぐらいネットで調べ「てく」ださいよ～～。
伝えるのめんど「い」し、説明上手くないからネッ-トで調べた方が絶対%絶対%にわかると思うんですよね。
お願いしますよ～～

**デフォルトの名無しさん** · 2023/07/03(月) 10:05:16.82

>>346
うわぁ～
怖い

引っ込んでます

**デフォルトの名無しさん** · 2023/07/03(月) 12:35:43.48

>>347
恐がらせてごめん。

**デフォルトの名無しさん** · 2023/07/04(火) 04:16:26.79

Nim言語はコンパイル時にreadFileとwriteFileを使えるんだけどコンパイル時にファイルを読み書きできるプログラミング言語ってあまりないんじゃないか?
staticExecていうコンパイル時にコマンドを実行できるプロシージャもあるし。

**デフォルトの名無しさん** · 2023/07/07(金) 02:08:00.59

どっかで既出かもしれんけど、結局VSCの拡張は何入れれば安牌？

**デフォルトの名無しさん** · 2023/08/01(火) 18:27:12.50

https://github.com/nim-lang/Nim/releases/tag/v2.0.0

**デフォルトの名無しさん** · 2023/08/02(水) 00:52:58.78

Nim 2.0がリリースされました。
https://nim-lang.org/blog/2023/08/01/nim-v20-released.html

**デフォルトの名無しさん** · 2023/08/26(土) 23:20:45.36

初めてお邪魔します

下のスレッドでフィボナッチ数列(回帰関数)のベンチマークをやったのですが
Nim 2.0がダントツの速さでした

原因が分かる方、教えていただけますでしょうか、よろしくお願いいたします

Qiita 3 - キータぞ、来たぞ、キータだぞー
https://mevius.5ch.net/test/read.cgi/tech/1685235361/368-371
https://mevius.5ch.net/test/read.cgi/tech/1685235361/373-375

上記スレ、fibonacci(44)の計算、抜粋

Nim(44はコマンドライン引数)
https://wandbox.org/permlink/WoYP0STRKxaRBGCY
>Time= 0.240s Result=701408733

C/gcc(44はソース直書き)
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang(44はソース直書き)
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

**デフォルトの名無しさん** · 2023/08/27(日) 00:54:05.78

>>353
Nimでコンパイルするときに'--listcmd'オプションを与えるとNimがgccを呼び出すときにどんな引数を渡しているか表示されるようになります。
もしかすると凄く最適化されるようなオプションを渡しているのかもしれません。

**デフォルトの名無しさん** · 2023/08/27(日) 01:58:10.81

>>354
早速の回答ありがとうございます

wandboxのspeedだとO3が見られたので、nim.cfgに gcc.options.speed = "-O2" を追加してついでに-d:ltoも外しました

Nim 2.0.0 + gcc 12.2.0(-O2) --verbosity:2 --listcmd --passL:-s (strip symbols)
https://wandbox.org/permlink/RVJ4eHKKl5DARK3u

>CC: prog.nim: /opt/wandbox/gcc-12.2.0/bin/gcc -c -w -fmax-errors=3 -O2 -I...
>Hint: /opt/wandbox/gcc-12.2.0/bin/gcc ... -lm -lm -lrt -s -ldl [Link]
>Hint: mm: orc; opt: speed; options: -d:danger

>Time= 0.274s Result=701408733
>Time= 0.252s Result=701408733
>Time= 0.251s Result=701408733
>Time= 0.250s Result=701408733
>Time= 0.250s Result=701408733

今度は確実に LTO無し gcc -O2 になりましたが、実効速度はダントツに速いままでした
何か気が付く点がありましたらまた今度教えてください (私の方は今日は限界です...)

**デフォルトの名無しさん** · 2023/08/27(日) 17:22:00.42

>>355
Nim言語が高速なのはC言語コードを吐き出した時に
再帰処理をgotoループに置き換えている可能性があります
その場合C言語のオプションをいくら変更してもあまり意味はない
です

確認はコマンドライン引数に --nimcache:.cache を加えて
コンパイルして.cacheフォルダ内のC言語ファイルを確認すれば
わかるはず

nim c --nimcache:.cache -d:release ...

-d:relsese の部分は -d:danger で置き換え可能で
dangerのほうが高速です

詳細はここ
https://nim-lang.org/docs/nimc.html

コンパイル型言語のベンチを取る時は再帰処理コードは
避けた方が良いと思います

**デフォルトの名無しさん** · 2023/08/27(日) 17:25:13.06

>>356 追記
末尾再帰になっている可能性もありかな

**デフォルトの名無しさん** · 2023/08/27(日) 22:36:37.59

Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
gccは再帰関数をループに置き換えているかもしれないからその確認をしたかったら-S -masm=intelを付けてアセンブリコードを出力させて読んでみよう。

**デフォルトの名無しさん** · 2023/08/28(月) 06:30:35.88

>>356
変換キャッシュの見方、ありがとうございます

>再帰処理をgotoループに置き換えている可能性があります
確認したところ、置き換わっていませんでした

>コンパイル型言語のベンチを取る時は再帰処理コードは
>避けた方が良いと思います
↑ここ詳しくお願いします

>再帰処理をgotoループに置き換えている
↑こうなっていませんでしたが、これ前提での話だったのですか?

再帰fibonacciは個別の言語コンパイラ(更にバージョン)の
最適化ベンチマークには持って来いに見えますので

**デフォルトの名無しさん** · 2023/08/28(月) 06:40:36.37

>>358
>Nimコンパイラ自体は再帰関数の最適化はしてなかったと思う。
その通りでした

確かめたところ二つの再帰関数コールがそのまま残っていて、
その他はNimのトランスパイル過程でのノイズがあるだけです

gccがノイズを消すために最適化を頑張った結果、Cより速くなったのですかね

**デフォルトの名無しさん** · 2023/08/28(月) 06:47:48.48

何気にNim + gcc HEADにしてみたら、更に速かったです

Nim 2.0.0 + gcc 12.2.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/RVJ4eHKKl5DARK3u
>Time= 0.250s Result=701408733

これ↑がこう↓

Nim 2.0.0 + gcc HEAD 14.0.0 -O2 (44はコマンドライン引数)
https://wandbox.org/permlink/cpYesJtnlRNJiu7Z
>Time= 0.197s Result=701408733

参考値再掲(>>353)
C/gcc -O2 (44はソース直書き)
https://wandbox.org/permlink/9OYZBH14tYooZHF7
> Time: 0.89583 seconds

C/clang -O2 (44はソース直書き)
https://wandbox.org/permlink/U97PecZYrzymnfH4
>Time=1.58712s Result=701408733

gccの最適化が凄すぎて意味わからないですが、ありがたく享受する事にします

**デフォルトの名無しさん** · 2023/09/06(水) 06:10:42.54

レバテックωωω
Rust in
Nim out
ωωωωωω

**デフォルトの名無しさん** · 2023/11/15(水) 08:06:37.71

>>349
F#が、 F# Dataってライブラリで、コンパイル時に
ファイルの読み取りは、やってたけれど、あまり見かけないね。

**デフォルトの名無しさん** · 2023/11/28(火) 09:23:46.10

happyxってdjungoの上位互換なれねーかな
https://hapticx.github.io/happyx/#/

**デフォルトの名無しさん** · 2023/12/06(水) 09:31:30.20

>>363
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2023/12/06(水) 20:32:47.84

Nim って python を強調し過ぎてるのはミスリードだと思うな
python と相性が良いってのは事実だけど Nim の特徴のほんの一部でしかない

**デフォルトの名無しさん** · 2023/12/08(金) 21:38:37.62

>>366
Python使える人が多いからNimを広めるためにNim言語はpythonと同じだという人は多い。
文法がpythonに近いだけで中身は静的型言語だからpythonよりC++とかRustに近いと思う。
pythonしか知らない人がNimのオーバーロードとかGenericsとかobjectとref objectの違いとかちゃんと理解して使えるのかどうか心配になる。

**デフォルトの名無しさん** · 2023/12/10(日) 11:41:19.18

「文法がpythonに近い」が事実じゃないんだよな
観た目が似てるだけであって文法が似てる訳じゃない
全然別物

**デフォルトの名無しさん** · 2023/12/10(日) 17:02:37.56

そういう意味では構文で結構損してそう
オフサイドルールが気に入らない人にとってはそもそも検討に値しないし
Python好きな人ならそこは気にならないだろうけど、別に移行しやすくもない

**デフォルトの名無しさん** · 2023/12/11(月) 04:52:12.28

>>369
でも静的型言語でオフサイドルールの言語はNimとcrystal以外あまりないのでは。
オフサイドルールが好きで型システムがちゃんとしていて高速に動くプログラムを書きたい人にはぴったり。

**デフォルトの名無しさん** · 2023/12/11(月) 06:10:19.79

型で安全性を静的に担保したいと考える人が、同時にインデントで意味が変わってしまうオフサイドを好むってのはちぐはぐさを感じる

**デフォルトの名無しさん** · 2023/12/11(月) 06:46:36.74

HaskellとデフォルトF#もオフサイドルールありですね。どうせインデントするんだしって使ってやれってくらいの感じなのかね？

あとは、インデントに意味はないけれど、goが標準のフォーマッタでインデント入れてくるね。

**デフォルトの名無しさん** · 2023/12/11(月) 06:54:57.74

Python登場当時だと{}前後のどこで改行するか論争みたいなのがあったりして確かに括弧書くのが面倒な空気はあったんだよな
それがGo/Rustの世代だと言語標準のフォーマッタが勝手にやってくれるってなって
めんどくさくないっていうオフサイドのメリットはなくなってしまった
そうすると自動フォーマットしづらいとかコピペしづらいとかデメリットばかり目立つことになってしまう

**デフォルトの名無しさん** · 2023/12/12(火) 04:50:08.02

ブロック毎に'{}'や行末に';'があるとソースコードが少し汚く見えるし
無いとすっきりして読みやすいと思うけどね。

**デフォルトの名無しさん** · 2023/12/12(火) 05:58:22.17

そんなの単なる慣れ

**デフォルトの名無しさん** · 2023/12/12(火) 08:04:30.17

まぁ人によるんじゃない
自分は{}がある方がブロックの識別性が良くて読みやすい
オフサイドは特にネストしたブロックの戻りが何段戻ったか見づらいんだよな

**デフォルトの名無しさん** · 2023/12/12(火) 08:08:33.42

カッコありなら、lisp系が好き。
悩む事が減る。

**デフォルトの名無しさん** · 2023/12/12(火) 13:00:45.46

>>374
セミコロンはオフサイドルールじゃなくてもRuby/Go/Kotlin/Swiftのように無しできるから関係ないよね

それにセミコロンをタイプするのは面倒だとは思うが慣れると読む時のノイズにはならない
自然言語の文章で句点やピリオド+改行がノイズにならないのと同じこと

**デフォルトの名無しさん** · 2023/12/12(火) 19:48:14.86

CやC++を10年以上使っていたけど';'や'{}'が無いほうがすっくりして読みやすいと思うから慣れでどうにかなるものでは無いと思う。
こういうのは個人差があるのかもしれないが