ID:2558326
 
Not a bug
BYOND Version:512
Operating System:Windows 7 Pro
Web Browser:Chrome 80.0.3987.163
Applies to:Dream Maker
Status: Not a bug

This is not a bug. It may be an incorrect use of syntax or a limitation in the software. For further discussion on the matter, please consult the BYOND forums.
Descriptive Problem Summary:

From the DM ref :

"This is used to access the procs and vars of a prototyped object. It is just like the . operator, but if the object is null, the access does not happen and there will be no runtime error. (A runtime error can still happen if the object is valid but is a different type that doesn't have the property available.)"

I would expect the access not to happen if the object returned has a false value, such as "0", but this is not the case. The object is accessed anyways, and since it's not the value we expect, it throws a runtime.

Code Snippet (if applicable) to Reproduce Problem:
// Some datum with an attribute I want to access
/datum/test
var/datum/data/D

/datum/data
var/number = 7 // A number we want to access

// A proc which returns the value
/datum/test/get_data(var/access)
if (access)
return D
return 0

// The proc to reproduce the bug

/proc/reproduce_bug()
var/datum/test/T = new
T.D = new

var/datum/data/my_data = T.get_data(FALSE) // This will return 0

if (my_data?.number)
return TRUE


Expected Results:

In the code provided, the "T.get_data(FALSE)" will return 0. I expected ".?" not to access the object and the `if (my_data?.number)` to return false.

Actual Results:

I have a runtime of the form :

Cannot read "0.number"



Does the problem occur:
Every time? Or how often? Every time.
In other games? N/A
In other user accounts? N/A
On other computers? N/A

When does the problem NOT occur? If I do not use "?." and instead do :

    if (my_data && my_data.number)
return TRUE


Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)

I think it's been here for as long as the ?. operator was introduced.

Workarounds:

See "when does the problem NOT occur".
Lummox JR resolved issue (Not a bug)
The ref clearly states this is a null check, not a falsehood check.