How to reproduce:

-- outputs zero
local b=band(nil,4)
-- throws error (arithmetic on field ?)
local b=nil<<4

I don't think nil should be handled in bitwise operators. It's not handled with any other operators, e.g. nil+4 would throw an error in standard Lua. That it worked before was a side effect of PICO-8 functions usually defaulting nil args to 0, which in this case they probably shouldn't have.

If you start handling nil as 0, then it becomes very difficult to find uninitialized variable bugs.

I know - innerloops are just so much faster without an if statement!
And it can be seen as a regression no? :]

I get that, but I think it's a dangerous feature to have and I personally would prefer not to have it vs. taking hours to notice that I typoed object.shjft.

When it comes to nils/nuls/NULLs/nullptrs/Nones you really want to crash early, crash often.

That being said it would be nice to have a ? postfix operator like some languages do, so you could do stuff like:

  obj = getobject()

  obj?:method()

  ↓ effectively means ↓

  if(obj) method()

It could probably also serve as a defaulting operator for numbers. The tokenizer/interpreter would need to understand context though, e.g. am I about to deref an object vs. am I using this variable in an expression.

But, at that point we're kinda getting into advanced language features and moving farther and farther away from what I think PICO-8 is meant to be. I'll leave decisions like these up to PICO-8's papa. ;)

This is also consistent with the rest of the API: math functions such as flr() or sin() treat nil as zero, and arithmetic operators such as % ^ and *= raise a runtime error.

fair enough - closing this post ;)