Naming convention for Pico8's overloaded functions

[jjant]

Description

Pico8 uses Lua as its scripting language, which allows overloading functions on the number of arguments it takes. For example, Pico8's spr function can be called in the following ways:

1. spr(n, x, y)
2. spr(n, x, y, w)
3. spr(n, x, y, w, h)
4. spr(n, x, y, w, h, flip_x)
5. spr(n, x, y, w, h, flip_x, flip_y)

We need to decide various things:

• Do we expose all 5 versions? We could, for example, only expose the most general one (5) and have the user write their shorthands.
• If we do expose all 5, how do we name them?
• We could also just have a general version with Option<T> arguments and expose that instead:

  fn spr(n: i32, x: i32, y: i32, w: Option<f32>, h: Option<f32>, flip_x: Option<bool>, flip_y: Option<bool>)

  IMO that's pretty ugly, and not much more convenient than having non-optional arguments (and have the user pass in the defaults).

We need to make sure that whatever approach we choose works for all of the Pico8 API functions.

[lesleyrs]

I'm guessing this https://rust-lang.github.io/rfcs/2137-variadic.html is unrelated as you can't specify the arguments? It's unstable anyway.

Is the purpose of the Option<T> just to be able to put none without having to know the default for the specific variable? That doesn't sound bad if you wanted to make it as easy as possible, but since this is Rust people may as well just find out what their function is doing right?

I dislike exposing all versions as the naming is not going to be obvious, but having another print function that automatically adds 8 to y each time you call it would probably be really convenient as that removes some overhead.

Edit: https://pico-8.fandom.com/wiki/DrawState wiki says the cursor advances y by 8 pixels.