udoprog
commented
2 years ago Thanks for the suggestion and sorry for late reply! I'll be going through some thoughts of mine below.
A handful of things speak against adopting quote's loop syntax (which was used initially). genco targets any language, including whitespace sensitive ones like python. So being parsimonious with "reserved" syntax is useful. We currently only reserve the use of #<ident>, #(...), and #_(...) IIRC. We avoid having to figure out how to solve ambiguous expansions like #(...)* where we actually want it to expand to the inner statement directly followed by a *. This is a non-issue with Rust's token streams (which quote targets) because adding a space there makes no difference in how it's parsed in Rust. Finally genco supports more control flows (match and if), so staying consistent across control flow structures is more important to me than doing the same as quote.
For string formatting. This syntax was chosen because building stringy things by providing the quote function with a pre-computed string can be quite intrusive (i.e. the string has to be computed outside of the quote). Formatting a string outside also necessarily requires extra allocations. You can see an example of what computed string are expanded to here.
Identifiers in genco do not exist in the sense as they have to be Ident tokens like they do in quote. Everything is literal values as strings (in one form or another), quoted strings, or various forms of whitespace. So we don't need to make formatting "identifiers" harder when we don't have the same requirements.
dvc94ch
So I've been using your crate and quite like it. Once I get some time I'll have to read the code to understand how it works. For 1.0 it might make sense to make the macro work like the quote crate, unless there's a good reason not to. The areas where it differs would be:
for loopvs#(#iter,)*#_(#str_1#str_2)vsformat!("{}{}", str1, str2)#(ident_1)#(ident_2)vsformat_ident!("{}{}", ident_1, ident_2)