List delete for index 0,-1... goes wrong

The result of this script is unexpected and inconsistent.
untitled script pic (57)

"delete idx of list" for idx:
0 - removes last element
-1.. - (last - abs(idx) )

Expected behavior (one of):
a)Throw an error for idx not belonging to [1..list.length]
b) Do nothing, at least for "0". Useful for
untitled script pic (58)
c) follow the JS for "splice" (idx < 0 as relative to end of list) AND b)

IMHO c) is the greatest result with minimal effort.

I think 0 should do nothing and negative numbers count from the end. (My PL enilKode would do that.)
EDIT: I agree with c)

I would throw an error for 0; I don't like it when a command does nothing because it makes code hard to debug. But this may be a losing battle; we inherited from Scratch any number of cases of a block silently doing nothing for bad inputs.

As for accepting negative numbers, I'm neutral, except to note that if we make that change in DELETE we should do it in all the List blocks that take index inputs, starting with ITEM.

What are some examples of this?

Thanks. I totally forgot about putting variables into the inputs. Most of those blocks prevent you from putting wrong values in by hand, so you would assume they would give an error with the wrong input, but they do not. I would argue for giving an error, if you really need the functionality of errors passing silently, just using a try-except block. In my opinion, giving no errors is useless: the block does nothing, but it also acts as if nothing is wrong. It is not as big of a problem with the blocks such as image, because the input obviously has to be a number..This could be especially annoying in cases like the image, as the input is not the wrong type, you could have just spelled a sprite wrong.

The original (Scratch) theory was, I believe, that errors are offputting to beginners and so there shouldn't be any.

The new (Jens) theory is that putting type checks in primitives is a significant slowdown of Snap!, and not useful in what is hopefully the common case in which the user didn't make a type error.

I agree that for our main use case of teaching teenagers computer science, an error message is much better than a silent failure, because it helps tremendously in debugging.

This is the one benefit of strongly typed languages (i.e., ones in which types are associated with variables rather than with values): They get to have their cake (catching type errors) and eat it too (no type checks at runtime).

Would this slowdown affect errors such as untitled script pic (10), where variable is not the name of a sprite, if such error checking was implemented?

Yeah, but I'm sure we do check that; you don't get an error message but you do get False, rather than Snap! blowing up.