macroquad::TextParams holds a reference to a Font that is stored in an Arc

[brittle lava]

Hey have you ever use TextParams from macroquad ?

pub struct TextParams<'a> {
    pub font: Option<&'a Font>,
    pub font_size: u16,
    pub font_scale: f32,
    pub font_scale_aspect: f32,
    pub rotation: f32,
    pub color: Color,
}```
I dont know how to use that thing because where do i store the fonts (all of that has to be cleanely stored in a struct)
and still build this holding a reference to the actual font ? (The core issue is that i will use this every frame so i need to store it but the fonts are loaded and stored in a Arc<Mutex<HashMap>>)

[lavish laurel]

You aren't supposed to store the parameters I don't think.

[lavish laurel]

If you are picturing it being called many times, that does not mean it is called in many places. Just fill in the parameters at the invocation site.

[primal fractal]

This struct is intendented to be constructed everytime it is needed, passed to a function, and forgotten about. not held anywhere for long periods of time.

[brittle lava]

but that means i would have to build it every frame ??

this doesnt seem very idiomatic, they could have just asked for an Arc<Font> instead of a reference

[primal fractal]

There's nothing wrong with building a struct every frame.
It's implemented like this to improve the readability of the function call. So that instead of looking like this:

draw_text_ex(
    "My Text",
    100.0,
    100.0,
    &font,
    12,
    1.0,
    1.0,
    0.0,
    Color::new(0.0, 0.0, 0.0, 1.0),
)

You call it like this:

draw_text_ex(
    "My Text",
    100.0,
    100.0,
    TextParams {
        font: &font,
        font_size: 12,
        font_scale: 1.0,
        font_scale_aspect: 1.0,
        rotation: 0.0,
        color: Color::new(0.0, 0.0, 0.0, 1.0),
    }
)

Which has the advantage of giving the arguments names, and has the same performance.

This pattern of taking the arguments to a function with a lot of arguments and wrapping it up in a struct is actually very idiomatic because it prevents people from staring at huge argument lists and not knowing which argument is which.

[brittle lava]

yes of course but what about giving a reference to that TextParams to the function ?

What if instead of building it it created it once with a Arc<Font> instead of &Font ?

wouldn't that work but better and faster ?

[primal fractal]

Taking a & to the Font is free, because it's just a matter of passing the memory address of the Font, which is always information that the compiler has to keep track of anyway. In contrast, in order to use an Arc here, you would need to clone it, which is not free. In fact, cloneing the Arc would take longer than constructing the struct, especially since constructing a struct is very likely to get optimized out by the compiler.

[lavish laurel]

building a struct is not an operation

the same data exists after doing so as existed before doing so

Arc is as much of a pointer as & is, so that doesn't matter either

there is no difference between these values being parameters to the function, and these values being fields of a struct you build in place that is a parameter to the function

[primal fractal]

I mean arc is more of a pointer than &.

Well, in the sense that there is more overhead.

[lavish laurel]

you wouldn't look strangely at a function taking all of these parameters

except for how many parameters there are, and how annoying it might be to understand what they do without inlay hints

hence, a struct, which has names.