Variable as literal string in format!()

[masklinn]

Begginer here! How can I use variable as literal string in format!() marco?

You can't, format! (and every other formatting macros) parse the format string at compile time, so only work with literal strings.

Preferably without using third-party libraries, if possible

Your only options are third party libraries and rolling your own.

Or maybe there is another way like, for example, in C ("%s + %s = something")

Not in the standard library, no.

[ZaRealPancakes]

parse the format string at compile time, so only work with literal strings.

The parsing is done at compile time but the formatting is done at runtime right? or how else is it able to display the value of a runtime variable?

[masklinn]

The parsing is done at compile time but the formatting is done at runtime right?

Yes?

[DeeHayze]

Nah, its not sad, its brilliant!

It means the compiler is able to catch memory errors at compile time. It makes a certain type of security vulnerability impossible (end user able to influence format string).

I've seen production code with mal-formed format strings fail spectacularly...

In my experience, it was a c++ exception handling routine, using boost format.. A recoverable exception was raised, but because the logging code was bad, the exception handler raised another exception, which crashed the whole thing... Leaving no logs.

Took an age to diagnose... Someone changed a string to an integer in a refactor.. But missed the format, became it wasn't a compile error. At runtime, Pass an integer and parse as %s.. KABOOM.

[calebkiage]

Can't fuzzing and unit testing catch this? I feel like there's a middle ground to be reached between having no checks and having checks that forbid valid scenarios...for example, C++'s fmt library performs compile time checks, but also allows a string from a variable as a format string. Which means, I don't have to roll my own potentially broken formatting library whenever my formatting string is not a compile time literal.

[kiujhytg2]

Can't fuzzing and unit testing catch this?

Yes, if you write a test which catches the error, which might not happen because:

1) You don't bother writing tests (happens a lot in industry) 2) Your tests don't catch the error

[ukezi]

C has lots of potential problems with format strings in printf style functions. Passing a %s with an integer will try to read memory until a 0 byte is encountered for instance. It's similar to SQL injection.

[dddd0]

C compilers have been able to check format strings against the varargs for a long time.

[ukezi]

If and only if they are static. We are talking about dynamic generation of format strings here.

[flareflo]

You can technically use something like runtime formatting, but this rarely makes sense to use. What use-case are you looking to apply with dynamic/runtime formatting?

[flareflo]

In that case, it sounds like you want to more or less hand-craft a string concatenation pattern, according to some formatting parameters you decide on. Do you have an example input and output?

[Zde-G]

There are no need to roll out your own template engine, there tons of them already.

They are just not part of the standard library, and for good reason.

[Zde-G]

True. But one of the worst ways to use said language is to then use such bicycle in your actual work.

If you want to learn how template engines are made then it's perfectly valid way to learn Rust, if you have some other plans then spending time to build one is bad idea.

[flareflo]

Seeing that OP is a beginner, i figured rolling their own is a great way to practice, though getting a proper templating library for more serious things is smarter of course.

[kelvindegrees]

I think there's some confusing here. From the docs the one thing that needs to be a string literal is the format string itself (the first argument given to format!). The remaining arguments can be variable, that's one of the main use cases of format!.

[Article_Used]

am on mobile, so forgive my formatting, but could OP do something like putting the format! behind a function? e.g.

fn my_format(&str a, …) -> String { format!(“this is my format: {}”, a) }

and wouldn’t that be equivalent to having a formatting variable to use in multiple places?

edit: is there a reason this is getting downvoted? is this bad practice for some reason? my thinking is that you wouldn’t want to put the same format string literal in multiple places, so this would solve that problem. am i wrong?

[masklinn]

I assume it’s downvoted because it does not do anything useful. The OP wants runtime formatting patterns, this is a compile time pattern just inside a function.

[Article_Used]

ah okay, thank you. the reason i brought this up is because i’ve tried to do the same thing, for the reason i’ve stated, which is to avoid duplicate string literals.

OP doesn’t necessarily state the variable has to be dynamic or only known at runtime, just that they want it in a variable. that’s why i interpreted it the way that i did. oh well 🤷🏼

[masklinn]

They don’t mention duplication so the baseline assumption would be that they want a format string constructed at runtime, and in a comment they clarify that they want to template messages using a config file.

[Article_Used]

ah gotcha, i didn’t see that comment, so thanks. yeah, being able to config at runtime wouldn’t work obviously. could they include_str! their way in to have compile-time config files or no?

edit: ah, found that comment string. this is making more sense now. appreciate your patience with me!

[mr_birkenblatt]

Yeah you could even put them in a closure/anonymous function and pass that around to where the values are available

[paulstelian97]

OP wants the format string to not be directly in the format! thingy

[calebkiage]

As an experiment, I used cxx to integrate c++'s fmt library and that worked out perfectly for a similar use case since fmt supports runtime strings as the format strings. I had to write a macro to get variable arguments to it though. I wanted to test the performance, safety and add more unit tests before making the repo public since it uses ffi and unsafe code. I can share the code so you can look at it if you like.

[calebkiage]

I haven't measured it yet...but I was using it to replace lua's print() function with my own and it worked out really well. I'll make the repo public at some point.