attempting to output the result of a initial() on an init[]'ed value causes runtime

ID:2122508
 
Jul 26 2016, 9:36 pm (Edited on Jul 26 2016, 10:26 pm)
BYOND Version:510
Operating System:Windows 7 Ultimate 64-bit
Web Browser:Chrome 52.0.2743.82
Applies to:Dream Daemon
Status: Open
Issue hasn't been assigned a status value.
Descriptive Problem Summary:
if you output the result of a initial() on a value that was init[]'ed at runtime (ie: list()) It triggers a runtime error saying "bad output value"

datum/testlist
    var/mylist = list()
mob
    verb/testlistworld()
        var/datum/testlist/T = new()
        var/l = initial(T:mylist)
        var/n = null
        var/e = list()
        world << n
        world << e
        world << l // <-- line 333


[21:26:53]runtime error: bad output value
[21:26:53]proc name: testlistworld (/mob/verb/testlistworld)
[21:26:53]  source file: client.dm,333
[21:26:53]  usr: (src)
[21:26:53]  src: MrStonedOne (/mob)
[21:26:53]  src.loc: the turf (1,1,1) (/turf)
[21:26:53]  call stack:
[21:26:53]MrStonedOne (/mob): testlistworld()


The biggest reason I bring this up, is because it shows something fucky happening with the typeid/value. initial(T:mylist) should return a null, but it returns something that acts like a null, but is not a null.

It also fails isnull().

Confirmed bug still exists in 511 latest
Jul 26 2016, 10:27 pm
I discovered this and worked with MSO to find some of it's quirks, but I'll just say something he missed:

If the list is owned by a datum (it's a datum var) you get this psuedo-null returned, however if it's a global or proc var you get a normal /list returned (which you can then output fine with no errors)
Jul 26 2016, 10:31 pm
The value of `wat` where the tests are run in http://www.byond.com/forum/?post=2024969#comment19919593 shows the same behaviour; truthy, "" as a string, not a list, not null, also runtimes "bad output value" if <<'d.
Jul 27 2016, 8:09 am
Technically the problem here is that initial(listvar) returns an expression reference from the compilation that holds no meaning at runtime. It's not null, but neither is it a meaningful value.

In a lot of ways this is a difficult fix. The first stage would probably be to tell the compiler that once it generates the init proc, the expression reference can be discarded and the value can be saved as null; that would make initial(listvar) come up as null, but it's better than the current behavior. I'm not sure about the feasibility of this.

The ideal behavior would be to create a new list per the original expression, but that isn't saved in the .dmb except as part of the init code. It would take considerable effort to do this right.
Jul 27 2016, 8:10 am
In response to CrimsonVision
CrimsonVision wrote:
I discovered this and worked with MSO to find some of it's quirks, but I'll just say something he missed:

If the list is owned by a datum (it's a datum var) you get this psuedo-null returned, however if it's a global or proc var you get a normal /list returned (which you can then output fine with no errors)

IIRC, global vars don't support initial() properly, which is why. And proc vars don't support it at all.
Jul 27 2016, 1:49 pm
In response to Lummox JR
I figured it was something along those lines yes, but I was just making sure to list the effects on the 3 different kinds of variables (I believe datum/global/proc are the only types anyway)
Jul 27 2016, 7:25 pm
In response to Lummox JR
Lummox JR wrote:
IIRC, global vars don't support initial() properly, which is why. And proc vars don't support it at all.

As far as I can tell, both global and proc vars behave identically when used in initial(); both just give their current value.