When issaved is called with a var name literal, it acts correctly.
When issaved is called with a text literal, it acts correctly? (by failing to compile).
When issaved is called with a var *value* in vars like issaved(vars[name]), it acts correctly.
When issaved is called with a var *name* like for (var/name in vars) issaved(name) it permits compilation but produces a result that at first glance seems incorrect, saying no member will be emitted to savefiles - even if they will be.
It may be difficult to initially grasp that issaved is not lying - but is being given the wrong variable entirely.
Numbered Steps to Reproduce Problem:
Try the below code.
Code Snippet (if applicable) to Reproduce Problem:
/datum/example
var/basic
var/static/other
/datum/example/proc/Check()
usr << "explicit basic: [issaved(basic)]"
usr << "explicit other: [issaved(other)]"
usr << "traversing var keys:"
for (var/name in vars)
usr << "\t[name]: [issaved(name)]"
usr << "traversing var values:"
for (var/name in vars)
usr << "\t[entry]: [issaved(vars[name])]"
/mob/Login()
var/datum/example/example= new
example.Check()
explicit basic: 1
explicit other: 0
traversing var keys:
basic: 0
other: 0
tag: 0
type: 0
parent_type: 0
vars: 0
traversing var values:
basic: 1
other: 0
tag: 1
type: 0
parent_type: 0
vars: 0
Expected Results:
keys produces the same results as values.
Actual Results:
keys produces all falsies.
Does the problem occur:
N/A
When does the problem NOT occur?
N/A
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked?
N/A
Workarounds:
Adding a warning box to the doc for issaved (like on the doc for var/tmp) that makes it clear that you must refer exactly to the *value* of the member var and not its introspected name would be nice.
