Oh, the general situation is something that might be common in C++, but in this specific situation -- the vector was created and held (and most probably being mutated) somewhere far away, and I have no clue what is being done with it -- and the relevant portion of the codebase is huge -- holding a reference is something I wouldn't dream of doing.
SubstructureFields could have had a lifetime parameter of something that was supposed to live longer, we can't be easily sure.
You can wrap the vector parameter or pointer/size parameter in a type, chase the compilation errors up to the places where the original vector exists, and make sure the usages there be well-protected.
That original vector could be used in a bajillion places all over the codebase (hint: It is. It's central to the AST representation in this case and is used everywhere). I'd be wading through a lot of code which doesn't even come close to the expansion phase.
This trick doesn't let me track the flow of a program to find out which portions of code will be run while my pointer is active. Tracking the flow only happens in Rust.
So it turns out you wouldn't be wading through a lot of code. Especially when it's in an AST, which, even if it's the sort of compiler that mutably updates its AST, probably isn't going to have surprise updates to source-position-tied attributes at macro-expansion time. Especially not when you have some basic const correctness to convince you of this in C++ (the equivalent of what we're seeing in this Rust code), but even in C and without const safety, and with a compiler that practices mutating an AST (with metadata) in-place, this would be a comfortable thing to do. (In C there'd be a clearly named function that adds "internal" attributes and you'd see its existence and where it's getting called, while in C++ if you didn't have type safety you'd make the field private, give the functions modifying it funny names, and grep for them.)
> Especially not when you have some basic const correctness to convince you of this in C++ (the equivalent of what we're seeing in this Rust code),
Const correctness has nothing to do with it. It does not enforce reference safety in C++, and the Rust compiler does not use "const correctness" to enforce proper memory management.
A const parameter in C++ tells you that nothing is going to be modifying the object in the body of the function you're writing, in which you're making a temporary reference to said object.
Unless you're trying to say that it's not a formal proof of correctness, but that's not an argument that engages with the claim the blog article made about whether this is something you would or wouldn't, or couldn't do, in C++.
SubstructureFields could have had a lifetime parameter of something that was supposed to live longer, we can't be easily sure.