4 ms·
> This makes them much easier to reason about and debug. Can you give an example of something that's easier to reason about (e.g., an error that's easier to sp
by creata 2y ago
> This makes them much easier to reason about and debug.
Can you give an example of something that's easier to reason about (e.g., an error that's easier to spot) with Zig's comptime than with macros?
> it makes other language features redundant
I'm guessing (so I might be wrong) that IDEs and users still need to be aware of the common idioms, so why does it matter whether or not those common idioms are implemented in the compiler or using comptime? (I'm not saying it doesn't matter, I'm wondering what benefits you have in mind.)
- WhyNotHugo 2y ago> Can you give an example of something that's easier to reason about (e.g., an error that's easier to spot) with Zig's comptime than with macros? Rust proc_macros takes a stream of tokens and return a stream of tokens. If your macro meant to return an instance of a specific type, it must output the correct tokens which create that instance via existing interfaces. There's some really ugly indirection in trying to understand what's going on. This is always harder to reason about than Zig's equivalent, because in Zig you just return the thing that you want to return.
- NobodyNada 2y agoHow does it work if I wanted to construct a type (and maybe a set of helper types. some related functions, etc.), rather than an instance of a type? If I just wanted to construct an instance of a specific type at compile time in Rust, I'd probably be using a const fn instead of a macro.
- cgh 2y agoYou return the type directly. You can then declare things to be of this type. Eg, from the Zig docs, here's how to construct a generic List type (note the comptime declaration of the generic parameter): fn List(comptime T: type) type { return struct { items: []T, len: usize, }; } // The generic List data structure can be instantiated by passing in a type: var buffer: [10]i32 = undefined; var list = List(i32){ .items = &buffer, .len = 0, };
- samatman 2y agoYou can't reason about macros, that's not how they work. You can read their definition, you can expand them, but there's no way to look at a macro call and reason about it, it can do anything at all. In C you don't even know what is and isn't a macro, so Rust has a modest edge in that respect. Zig just doesn't have this problem to begin with.
- creata 2y agoReading a macro's definition and reasoning about its effect is... reasoning. It's not the same as reasoning about something using its inherent limitations, which is the kind of reasoning that I think you're referring to, but it's still reasoning.
- samatman 2y agoOk, sure, we can reason about anything. We could reason about machine code, if we had the time and inclination. I barely participate in Hacker News anymore because it seems to have collectively lost the ability to extract meaning from words, unless an exhausting and totally excessive amount of attention is put into satisfying a misplaced sense of precision. There's no intellectual charity left and it sucks.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- dabinat 2y agoI have difficulty debugging proc macros. If I need to output some data to aid in debugging a derive macro, the only way I could think of to make that happen was to make it panic with the data as part of the message. This feels like a very clunky way to debug.