If you have a format string that long with arbatary expressions putting them all raw in the format string is not going to improve much. Better to give them actual names first.
in this case it’s about 80% function calls. They’re convenience functions for assembly instructions, so they’re of the form:
load(Reg::D, "A"),
load_const(5),
which is more useful than variables would be. I guess i could use .join or a crate like concat_string? Either way i sorely miss arbitrary expression format strings from python =(
As far as I remember, the point for not allowing arbitrary expressions is that it makes what looks like formatting an arbitrary complex operation and that it doesn’t improve readability that much.
Although sometimes I miss being able to refer to fields in format, for function calls and especially this many, I agree with an advice to put strings in a vector and joining them. Plus, there is a limit to how many arguments format macro can accept, iirc
it makes what looks like formatting an arbitrary complex operation and that it doesn’t improve readability that much.
What’s silly to me about that reasoning is that all workarounds are equally less convenient, have less readability, and the effect is identical to just letting me put whatever between the brackets. I genuinely dont understand the downside i guess.
Calling .join on a vector can have side effects too, except the “we’re concatting strings” is at the end rather than the beginning (and could obfuscate the fact that the end result is a string). It has just as much room for abuse as a long format!(). Even with just format!(), anything you could do inbetween the brackets, you can do outside the brackets in the arguments anyway. At least when it’s between the brackets, i know exactly where it’s going and when without having to juggle the string pieces and assemble them in my head.
Well, that’s all true from an end user perspective. But consider that format! is a macro and as such it should process its format string. Calling something from inside evaluation of a format string really does seem weird in that regard
You can give it variables:
let foo = 4; let bar = "bar"; format!("{foo}{bar}");If you have a format string that long with arbatary expressions putting them all raw in the format string is not going to improve much. Better to give them actual names first.
in this case it’s about 80% function calls. They’re convenience functions for assembly instructions, so they’re of the form:
load(Reg::D, "A"), load_const(5),which is more useful than variables would be. I guess i could use .join or a crate like concat_string? Either way i sorely miss arbitrary expression format strings from python =(
Creating an array of the function calls, and joining those seems more readable in that case.
Plus you don’t have to take care that you use the correct number of placeholders.
As far as I remember, the point for not allowing arbitrary expressions is that it makes what looks like formatting an arbitrary complex operation and that it doesn’t improve readability that much.
Although sometimes I miss being able to refer to fields in format, for function calls and especially this many, I agree with an advice to put strings in a vector and joining them. Plus, there is a limit to how many arguments format macro can accept, iirc
What’s silly to me about that reasoning is that all workarounds are equally less convenient, have less readability, and the effect is identical to just letting me put whatever between the brackets. I genuinely dont understand the downside i guess.
Calling .join on a vector can have side effects too, except the “we’re concatting strings” is at the end rather than the beginning (and could obfuscate the fact that the end result is a string). It has just as much room for abuse as a long format!(). Even with just format!(), anything you could do inbetween the brackets, you can do outside the brackets in the arguments anyway. At least when it’s between the brackets, i know exactly where it’s going and when without having to juggle the string pieces and assemble them in my head.
Well, that’s all true from an end user perspective. But consider that
format!is a macro and as such it should process its format string. Calling something from inside evaluation of a format string really does seem weird in that regard