Now that we know that is* are different from istype, and are based off of looking at the typeid of the value struct, not the type of the thing referenced It seems odd that islist doesn't exist, as that's a different typeid from anything else checked with a is* builtin.
Edit, on that note, should probably have one for any other typeids that could show up in a var that game code might care about... but i think islist is the only one missing.
ID:2093738
 Jun 3 2016, 4:05 am
|
|||||||
| |||||||
Meh, I just in general think it would make the language more complete if every typeid (and maybe a few composite typeid sets like an isdatum and an isatom (and maybe even an ismovable if you feel wild)) had is* handlers now that I know how they work and that check something different then istype()
Obviously it depends on the standard time to implement vs benefit factor | |
Time to implement is probably quite low. Benefit is also quite low, except that would change if /list were made inheritable. In that case islist() could be highly beneficial.
| |
/list were made inheritable. Would dovetail nicely with operator overloading and /list subtypes (queues, stacks, unique-arrays, sorted lists, metatables, leveled lists, and weightlists, here we come!) | |
Internally I suppose it would shortcut a couple of switch() case checks and proc calls, if it were implemented as a direct instruction, but it's not much of a speedup because ultimately there'd be no need to climb the prototype tree.
Of course if I ever get around to allowing /list to be subtyped, then that equation changes.