3 ms·
> Go also defines int to be the size of the native integer register size on the target arch Which is quite redundant, not to mention causes issues when portin
by apta 8y ago
> Go also defines int to be the size of the native integer register size on the target arch
Which is quite redundant, not to mention causes issues when porting between different architectures. Rust does the right thing by using `isize` and `usize` to make it explicit.
- nickmqb 8y agoI agree that Rust takes the right approach. Muon follows it, the corresponding types are ssize and usize.
- andrewchambers 8y agoUmm, I don't think you understood his comment... The rust way would be i64, not literally 'ssize'.
- nickmqb 8y agoI'm not sure that I follow you, just to clarify: Muon.ssize == Rust.isize == Go.int ('usually', according to https://tour.golang.org/basics/11 https://tour.golang.org/basics/11) Muon.usize == Rust.usize == Go.uint Muon.long == Rust.i64 == Go.int64 This is a list of all core types in Muon: https://github.com/nickmqb/muon/blob/master/docs/muon_by_example.md#core-types https://github.com/nickmqb/muon/blob/master/docs/muon_by_exa...
- tagrun 8y agoIt isn't redundant because that's the only type in Go which does that. There is no issue because int is explicitly defined to mean the CPU word. As I already mentioned above, due to how its meaning mutated and got distorted over time, it may be better to use a different word. usize/isize is also fine IMO.