let s = f!("{} | **{}** will attack **{}**.",
const { DamageType::Bruise.emoji() },
user.name,
target.name
);```
The first expression can be evaluated at compile-time, while the others not.
I've tried using the const_format crate to build strings at compile-time, but I was unable to effectively combine it with runtime string building. This is because const_format is designed to work exclusively with compile-time expressions, and it doesn't provide a seamless way to integrate with runtime string manipulation.
Is there a solution for this?
#Is it possible to mix compile-time and runtime string building (similarly to C)?
22 messages · Page 1 of 1 (latest)
I don't think so, no.
Not without manually reimplementing a lot of const-format to make it more versatile.
Honestly I'd just do this at runtime tbh
f!, assuming it's an alias for format!, will allocate anyway. The time to format an emoji into a string there should be insignificant compared to the rest
Yeah it's format!
I made this alias since I use it frequently
I'm really curious why Rust doesn't support it yet
Honestly, because it's useful to almost nobody.
almost, since you're a living exception, but it generally just does not come up
Combine with the fact that whatever you're using the formatting machinery for will probably be slow-ish on its own even without formatting and adding the necessary complexity to let you partly format strings was probably seen as unnecessary?
If I was const-format, I would see this as something that isn't actually necessary to support, at least.
And std doesn't support it because it processes the format string in a macro, which runs long before const does.
I didn't know it was slow on it's own
But I'm taking the easier to maintain route
Thanks
Allocation is not that slow, but whatever you're doing with that string will probably involve displaying it, and that's unlikely to be fast in any absolute sense
Is there a higher price when building a String via format! over using push_str() ?
Just for curiosity
I would say yes. the fmt system is much slower than it could be, but it strikes a reasonable tradeoff between compile time/binary size/performance
That's fair