Any future plans for impl for multiple types?

Thats a simple example, macros can get very unrully and be a waste of time depending on what you're working on. Make a nice API for a bunch of library users ? Worth it. Try to get rid of some boiler plate and repetition ? Not worth it. When I start to get into callbacks and munchers in macro_rules, I know its a sign to just stop messing with it.

That's quite an assertion, and it's empirically false. The whole point of macros is to generate syntactically similar pieces of code that can't otherwise be expressed via generics. I have written countless simple macros for bulk implementation of traits.

Most macro_rules use cases (including repetition) do not require TT munchers. This is a strawman argument.

1 Like

To clarify, I was speaking from my experience so far and how I've approached it, since it seems every time I try to write a macro for something, a simple example like you gave isn't enough.

Its not a rule or a stament of how everyone else should think about it. Just how it has been for me so far.

2 Likes

This doesn't change the fact that various tools interact badly with them. Starting from IDEs and then linters and bunch of others.

But the most eggregious issue are compile times. If I want to use 100 template functions with 100 types then that doesn't mean I would use all 10000 functions, but that's precisely the only choice macros give me.

And don't even start on five-argument functions with five possible types in them! In that case I would typically used dozen of functions out of three thousands generated by macros!

Macros are incredibly inefficient and cumbersone even if you compare them to C++ templates. And are much worse than Zig's comptime handling of types.

P.S. But I guees that's progress from @H2CO3 stance who was complaining about how I don't understand the beauty of generics when I complained about Rust's macros generating less readable error messages than C++ templates. If the official stance is to say that templates are not present in Rust because Rust have macros then this deficiency should be addressed, somehow.

That's a problem with the tools, not with the macros.

I can write a half-assed compiler that only accepts 10% of Rust's features and rejects or miscompiles the rest. That'd be clearly my insufficiently advanced compiler's fault, not the fault of the language features.

You are repeatedly making general statements. My problem with this attitude is that it just doesn't stand up in the face of reality. Macros are great for what they were invented for. Yes, sometimes macros are not the solution. But that doesn't mean they are always "inefficient" and "cumbersome". If they always are, then you are holding them wrong.

A programming language has several layers. It has syntax and semantics, to begin with. Sometimes, one wants to abstract syntactically. Sometimes, one wants to abstract over types. There are different tools for solving these problems. If you don't get that, then you don't understand programming.

No, that's problem with the macros, first and foremost. They accept arbitrary sequence of tokens, tools couldn't, in general, know which part of them are Rust and which part of them are not Rust.

Even when it does?

Everyone else, too? Like: do you even know why diesel have 32-column-tables, 64-column-tables, 128-column-tables?

In some languegs, sure. In Rust macros are used for both and while they work great for introduction of a new syntax they don't work so grat for working with types in ad-hoc manner. But people are using like that for there are no other choice.

I'm making statemepts that read careful reading. Take that statement that you object to:

The full form would be “Macros [in Rust] are incredibly inefficient and cumbersone even if you compare them to C++ templates [if you compare them on tasks that are solved in Rust with macros and in C++ with templates].”

Sure, that part in brackets was omitted, but isn't that obvious from the context?

Yes, some tasks couldn't be solved with C++ templates. But comparing two solutions, one of which works, and other doesn't work is stupid. And when Rust macros are used as poor mans replacement for C++ templates they are harder to use in almost all cases: error messages are worse, tooling are less useful, etc.

And you, while complaining how my general statement are useless never offer a concrete counterexample where they are wrong (which would be useful criticism), but just baselessly complain that they “doesn't stand up in the face of reality” and instead write equally useless statements like “macros are great for what they were invented for”. Well, sure: macros are great when they are great and macros suck where they are not great.

We are discussing precisely the form where they are not-so-great so why do we need to mention that they may shine somewere else?

seems like you’re asking for duck typing