ID:2344098
 
BYOND Version:511
Operating System:Windows 10 Pro 64-bit
Web Browser:Chrome 63.0.3239.132
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
Trying to locate an /obj or /mob(I assume this will happen to /turf and /area aswell) when you give '/atom' or '/datum' on locate() (both for in world and in containers check).

Numbered Steps to Reproduce Problem:
Should be self-explanatory with the code

Code Snippet (if applicable) to Reproduce Problem:
/client/verb/locate_test()
var/list/L = list(new /obj)
var/obj/A = locate(/atom) in L
var/obj/B = locate(/atom/movable) in L

world << "A: [A]"
world << "B: [B]"


Expected Results:
A: The obj
B: The obj

Actual Results:
A:
B: The obj

Workarounds:
Manually looping the list and doing an istype() check on each element.
I'm curious how this came up, since it's unsafe to cast an atom or movable as an obj. It'd be normal to do something like this:
var atom/movable/A = locate() in L
It very likely breaks even if A and B isn't typed.

As far as i know, the typing of vars doesn't persist into runtime, instead the compiler handles encoding that info to opcodes that care about that.

In response to MrStonedOne
You're quite correct: Type info about vars is not stored in the .dmb at all. The compiler simply interprets instructions like locate() and for(A in B) loops so as to include the appropriate information.