Araqが, unsignedを嫌ってるという話を前にしたかも知れない. nimは, unsignedを使いにくく意図的に設計されてて, その意味が全くわからない(Cと同じにしてくれよ)のだが, Araqいわく, 「unsignedはセマンティクスが(ry」とのこと. 結論としては, コンパイラの実装を考えた場合, unsignedを軽視するのが良いらしいのだがピンと来ない.
だけど, 使い勝手でいうと, 整数に関して定義されるarithmetic operationsは, 単なるbit operationsなので, singednessは大して意味がないというのは理解出来る(それに人間に対する表現としてしか意味がない). つまり重要なのはbit-widthのみということになるということも理解出来る. よって, AraqがC世界のu32をint32でusuallyマッピングすると言ってるのも理解出来る. Nimは, この点を強く強調している言語なのだろうが, その理由は理解出来ない.
とりあえず, 盲目的なプラクティスとして, signed型を使う方がnimとの親和性は良いということは言える. なので, nim-fuseについて, lowlevelのインターフェイスについてはそうデザインしようと思う. highlevelについては, これはCの完全なるコピーにしようと思う. ここでオリジナリティを発揮してnimishだとか言っても, あまり意味はないし却ってわかりにくくなる. ただし, posix.nimにある型は積極的に使っていこうと思っている.
10:39:31 akiradeveloper I know Araq don't like unsigned int. So it's usually recommended to use signed int? If we are interfacing unsigned values in C? 10:40:19 Araq usually in C "unsigned" doesn't mean much. the C developer thinks it means "natural number" but this is just wrong 10:40:41 Araq so I usually map it to a signed integer of the same size 10:41:59 Araq but that's what I do I don't think there is a consensus really 10:44:00 akiradeveloper You know I am developing fuse binding and once I design the interface to use unsigned a filesystem implementation needs too much casting 10:45:01 akiradeveloper Really annoys me... So I am considering rewrite them by signed. I don't use windows.nim that's what I picked while researching 10:46:35 * TEttinger quit (Ping timeout: 264 seconds) 10:48:16 akiradeveloper inode number is 64bit unsigned for filesystems to have 2^64-1 inodes... This sounds to me not misuse of unsigned value 10:50:02 akiradeveloper I think it's convenient that numerics are the same in C if it's not ideal. especially if we are interfacing with C 10:58:19 * sepisoad joined #nim 11:02:23 Araq *shrug* do what you think is reasonable 11:02:58 Araq obviously it's important to be able to habe 2^64-1 inodes as 2^63-1 would be too few of them 11:03:06 Araq *to have 11:03:36 czr for inode numbers it's actually somewhat complicated. on some filesystems they should be treated as unique identifiers for inodes (the fs will allocate them), on others you can actually discern some .. meaning of the value (ext-family) 11:03:37 * sepisoad quit (Read error: Connection reset by peer) 11:04:13 czr so yes, it's quite possible and within POSIX spec to allocate an inode "number" that has highest bit set. however, since it's to be treated as opaque data, it probably doesn't matter. 11:07:54 gokr Btw, debugging huge.nim works great in QtCreator. 11:08:09 czr the only operation that is "useful" in userspace with inode "numbers" is comparing two inode numbers for equality. any other operation is meaningless really. 11:08:19 gokr It can also use the nim syntax highlighter for Kate. 11:10:11 Araq czr: exactly, thank you. 11:10:30 czr np, sorry for barging in :-) 11:11:37 czr however, if you're providing an interface for existing linux/posix API, the path of the least surprise for the user of the interface is retaining exactly the same types, unless you're attempting to hide the underlying API. for FUSE it doesn't seem like a good idea 11:11:55 czr akiradeveloper, ^ 11:12:36 czr akiradeveloper, btw, are you wrapping libfuse or talking fuse directly with kernel?