I've noticed that there is no
type block
Could we have one please?
Preferably in the standard blocks not the extra list library
I'm suspecting that this is deliberate omission and that an explanation is heading my way instead 
Yes and no. Yes, in the sense that it's occurred to us that there's sometimes a need for such a block and we haven't prioritized it. No, there isn't a reason we think it'd be terrible to have it.
One small design question: What if the item isn't in the list? What if it's in the list more than once? People might have different ideas of what they'd like the block to report in those cases. If you write it yourself, you make those decisions for yourself.
I don't know about Jens, but one reason that block as a primitive doesn't appeal to me is that, the world being what it is, people who've learned one of those bad grownup languages have the habit of writing FOR I=1 TO (LENGTH OF LST)-type code, and I don't want to encourage them to focus on indices. Much of the time, a HOF, or at worst FOR EACH ITEM, is a better approach to a problem.
That's not an argument that would make me want to forbid you using INDEX OF; if you're trying to write Quicksort it's crucial. Just an argument for someone other than me to do it. :~).
I dunno, what do other people think? @jens @bromagosa @cycomachead @jguille2 @everybody...
I've seldom needed to have it. As Brian says you usually have a more abstract / functional way to deal with lists where you don't need to care about indices.
In the rare cases where you do need it, I think it's easy enough to implement it. Can you share your particular case?
Here's my take on it:
I'd be much cleaner if you didn't need to care about the case where the element is not in the list at all...
For most purposes I'd use = rather than IS IDENTICAL TO. But otherwise that's how I'd write it too.
dito for me. I rarely need to find the index of an element. Basically I claim that if you need the index of an element in a list that indicates you're probably wanting to use an imperative command mutating the list such as INSERT, REPLACE or DELETE. I don't mind you doing that, but I don't want to encourage it either. Instead we now offer powerful blocks to filter, map, find and combine elements of a list. So, if you need INDEX OF, I think it's alright to write your own.
BUT, I'm really curious, Simon, about the use cases you have in mind. Can you tell us some more about these. See, I might be swayed....
I discovered there was was no index reporter when trying to insert a new item in a sorted list
I was looping thru sorted list and was testing to find insertion point and wanted the index of that point.
I found that even the library had
but no simple index of block
As an aside, I came up with this method instead, so the lack of one made me approach the problem in the proper Snap! way 
I just feel its some sort of fundamental list reporter and there shouldn't be a need to roll our own (unless basic one doesn't do the job required)
But I'll downgrade request for it just to be in the list library
I think "standard" approach is to return index of 1st item found in the list
And because Snap is 1-based indexing, then 0 jumps out at me for not found result
1 Like
If you're inserting into an already-sorted list, you can
which makes a new list rather than inserting into the old one.
(By the way: Instead of doing screen captures, you can right-click on a script and choose "script pic" and Snap! will make a beautiful picture of just the script, no background.)
btw, no need for WARP here
Unfortunately, because of saving issues with Scratch 3, I have to set my browser to ask for a filename to save downloads to and therefore I don't get easy access to the image - I have to download it then load it into an image editor and then copy it before pasting into forum so I just go for using the Win10 snippingtool
Ah. I just set my download folder to Desktop.
Okay, I just found a use case for "index of": Determining the layer of a sprite:
2 Likes
I've just remembered that I can just drag the image into the forum once its downloaded
1 Like
This is mostly to respond to Brian's point of "what should the reporter do when it's not there, or when there are multiple items" -- it feels like the call should be "indices of ELT in DATA", and return a list of the indices. There's a kind of clumsy way to do it in snap, by attaching a list of the indices (numbers 1 to length of DATA) with double map, listing them together, then keeping those whose ELT matches the hole, then mapping across it again to remove the element and keep the indices. Count me in for one vote of "it would be nice to have this in the list library and be relatively fast".
Well, that would definitely have the virtue of teaching kids the plural of "index." :~P