I was thinking that a really neat feature would be that the primitive shape drawing functions accept tables as arguments. I'm not sure whether that conflicts with Zep's ideals of what the PICO8 environment should be like but I'll list a few pros. First of all, an example of what I mean.

rec={60,60,68,68,14}

--basic way to pass
rect(rec[1],rec[2],rec[3],rec[4],rec[5])

--proposed syntax
rect(rec)

--traditional Lua; achievable in PICO8 at the cost of the tokens
--required to define unpack
--see: https://gist.github.com/josefnpat/bfe4aaa5bbb44f572cd0#unpack
rect(unpack(rec))

As you can see, this requires far less tokens/characters which is great for tweetcarts and code golf - things that PICO8 really shines at. It would also be useful in larger projects where the bottleneck is usually compressed size/char counts rather than token counts (defining objects is still kinda costly).

It would also be useful for functions like

foreach(tbl_of_recs,rect)

or some more complex scenario that needs to save memory by using shared references to the 'rec' table (a bit far-fetched but not unimaginable haha).

I imagine that push-back for this request might come in the form of "it's too convenient". To that I would say, not really. When you consider that the task is really to send some values to the graphics "hardware", this isn't really too much to ask. In old consoles you would arrange this as a blob of contiguous bytes in memory and feed them to a register, perhaps even with an auto-incrementing pointer. Passing the table as a whole isn't really much different from that. Besides, this format still has a downside in that it uses the array part of a table and x2/y2 can't be lazily calculated using a width/height var:

rec={60,60,68,68,14}

--move the rec
if(btn(0))rec[1]-=1 rec[3]-=1
if(btn(1))rec[1]+=1 rec[3]+=1

--as opposed to
rec={x=60,y=60,x2=68,y2=68,c=14}
if(btn(0))rec.x-=1 rec.x2-=1
--...

That's not as pretty or elegant as a hashmap with X/Y elements that larger projects tend towards. So it really is geared more towards the tweetcart domain. It could be a possibility that the functions also read named fields such as x,y,w,h,c and such, but I think that is a little too much to ask for.

In any case I think this would be a great addition to get some more mileage out of tweetcarts and other restrictive challenges. I would welcome it for all drawing functions, but I understand how that might be a little too much? I dunno. For rect/circ & friends I think it would be great.

Thanks.

I think having all functions optionally take tables as replacements for arguments could be problematic, since some functions take tables to begin with.

However, I'd get behind this as far as having a built-in unpack() (as found in vanilla lua) to convert tables to tuples/arguments.

With that, you could write a foreach() that just does an implicit unpack for each element, since foreach() is already just a lua function that's provided at runtime.

Unpack would also be cool. It accomplishes the same thing but just costs a wee bit more than passing just the table, and would be useful in other scenarios too.