3 ms·

I wonder if macros are a type of magic that can be reasoned about more sanely than other types of magic?

• dathinab 4y ago
  The handlers are less hard to reason about then a lot of macros. You don't have to understand the type magic which makes them work. At least if you look at the more relevant frameworks (actix-web, axume) they basically boil down to calling a fn foo(x: A, y: B) -> Result<Body, Error> as roughly let x = A::from_request(&req, &mut payload).await?; let y = B::from_request(&req, &mut payload).await?; foo(x, y)?; and _nothing_ more. There is no special handle first/last parameter different logic or anything. They way they handle not copying the payload (request body) is by moving it (a reference to it) out of the request (or here payload). The reason the performance for micro-benchmarking extractors is different depending on the order has less to do with the general design and more the typical "I reordered parameters and now optimizations trigger differently" problem. (Probably some in-lining and const propagation allowing eliminating some checks but just on one order, anyway not specific to web frameworks at all and can also happen with their approach, but probably less likely if I should guess).
• twic 4y ago
  No, indeed, the opposite. In Rust, these will surely be procedural macros, which comprise functions written in Rust which operate on Rust code, represented as token streams. The compiler compiles the macro, lexes your code, feeds it to the macro, gets a token stream back, parses that, and that's what it compiles. Understanding a magic handler function involves understanding a particular subset of features of the Rust type system, and operating that mechanism in your head to see what happens. Understanding a proc macro involves understanding arbitrary Rust.
  • fire 4y ago
    ...oh dear