if changing the behavior of `type` is considered a bad idea
IMO, it's a bad idea to break compatibility with widespread check:
if type(v) == "table" then
I'd love to at least see some other function that behaves like this
The similar problem with numeric subtype was solved by introducing math.type()
So, it might be a good decision to introduce table.type()
If there is no "__name" metafield, table.type() may return "table"/"userdata"
You may ask:
Why should this function be located in the "table" library while it should work with both tables and userdata?
My answer: Why not?
We already have functions in the "math" library working with strings: math.min(), math.max()
math.min("11", "2") == "11" -- contra-mathematical behavior
So, why not have a function in the "table" library working with userdata? :-)
