3 ms·
> If you need to read in 1M integers, put them in a file and read them in. ..and if you're in a context where you need that data in the binary, because you don
by wtetzner 3y ago
> If you need to read in 1M integers, put them in a file and read them in.
..and if you're in a context where you need that data in the binary, because you don't have a reliable place to store a file?
> That's now extra code to maintain in the compiler just to support a behavior that should be discouraged.
If you don't want to maintain the code to properly support a language feature, don't include that feature in the language.
- tialaramex 3y agoFor a compiled language it seems reasonable to assume that "put them in a file and read them in" means at compile time, like the C23 pre-processor feature #embed and the Rust macro include_bytes! Now, #embed and include_bytes! always give you bytes (in Rust these are definitely u8, an unsigned 8-bit integer, I don't know what is promised in C but in practice I expect you get the same) because that's what modern files are - whereas maybe you want, say, 32-bit big endian signed integers in this Swift example. But, Swift is a higher level language, it's OK if it has some more nuance here and maybe pays a small performance penalty for it. 10% slower wouldn't be objectionable if we can specify the type of data for example.
- wtetzner 3y ago> But, Swift is a higher level language, it's OK if it has some more nuance here and maybe pays a small performance penalty for it. I thought the concern was about compile time performance? I'm not sure what Swift being higher-level has to do with that.