Time  Nick      Message
00:18 MTDiscord <luatic> btw how do we feel about std::size_t vs size_t
00:18 MTDiscord <luatic> supposedly the former is more lawful
07:18 sfan5     I use the latter
10:50 [MatrxMT] <Zughy> sfan5: why possible close on #14643 ?
10:50 ShadowBot https://github.com/luanti-org/luanti/issues/14643 -- Add Active Object Spatial Cache by ExeVirus
10:53 sfan5     mutually exclusive with luatic's PR
11:41 MTDiscord <josiah_wi> If you want the most lawful size type for working with a standard container, it's the size_type attribute of that container. 🙂
16:54 Desour    I definitely prefer size_t. std::size_t (or even the container's typedef) is just too verbose
17:34 [MatrxMT] <grorp> merging #15972 in 5 min
17:34 ShadowBot https://github.com/luanti-org/luanti/issues/15972 -- lua_api.md: Mapblock-related and misc improvements by grorp
18:45 MTDiscord <herowl> Just using std::size_t; and you've got your lawful usage...
18:47 MTDiscord <herowl> Or import a container typedef
18:47 MTDiscord <herowl> Potentially abuse auto
18:48 MTDiscord <herowl> Anyway, I really don't like size_t in loops, especially with non-trivial increment/decrement logic.
18:48 MTDiscord <herowl> (unsigned)
23:35 MTDiscord <luatic> it looks like our operator[] on vector(2|3)d is UB.
23:35 MTDiscord <luatic> it also looks like compilers can't optimize a switch that effectively does array indexing, even if the struct is laid out like an array.
23:37 MTDiscord <luatic> in practice the UB is hopefully not a problem but who knows.