BB_C

Not only that. We don't just "inject" raw strings with the syn/quote duality. Stringified or not, the token tree will be parse-checked into the expected syn type before being used in generated code.

So the distinction is both wrong and irrelevant. This is what I meant by wrong on multiple levels/layers 😉

In Rust, you provide a string — that is injected to be invoked internally. In C++, we’d just provide a callable.

This is because Rust’s attribute grammar can’t support a callable here.

I don't do C++ as a life choice, and thus not 100% sure what the author means here. But I have the feeling that he is wrong, on multiple levels even 😉

I just looked at the code, and it's actually a neat idea implementation wise, and I see now how it helped you.

But I'm still of the opinion that its a purpose mismatch.

Last week I basically duplicated the serialization code to provide better debug output…

Why was duplication needed, instead of implementing Debug using serialized output?

And why would one want to rename stuff...etc in Debug anyway? It's for debugging?

This looks like purpose mismatch to me.

Also:

A short post on how variable names can leak out of macros

I don't think you understood the blog OP!

There is a general mechanism in Rust that allows language users to add their own sugar. It's called macros 😉

macro_rules! keep {
    (let $id:ident = $expr:expr => $($tt:tt)+) => {
        let $id = $expr;
        let $id = $id$($tt)+;
    }
}

fn main() {
    keep!{ let path = std::env::current_dir().unwrap() => .as_path() };
    println!("{path:?}");
}

You can remove let from the macro's fragment specifier and invocation.

mastering_rust

Maybe wait until you're actually good at it.

Rebinding with and without mut is a known and encouraged pattern in rust. Leaving things as mut longer than necessary is not.

Bringing vimperator/pentadactyl back! That would be the dream.

Anyway, last time I tested it (~3 weeks ago), servo was not very usable still with the few websites I tried. Hopefully it gets, at least partway, there in a few months.

Neither.

• make new() give you a fully valid and usable struct value.
• or use a builder (you can call it something else like Partial/Incomplete/whatever) struct so you can't accidentally do anything without a fully initialized value.

Maybe you should also use substructs that hold some of the info.