ID:2744406
 
Applies to:DM Language
Status: Open

Issue hasn't been assigned a status value.
Scenario:
/mob/living/player
name = "player"

/mob/living/player/proc/updateUserData()
//stub
return

/obj/wand
var/mob/living/player/owner

/datum/spell/fireball
var/obj/wand/spellcaster

/datum/spell/fireball/proc/Attack()
var/mob/player/O = spellcaster.owner
O.health += 15
O.xp += 50
O.updateUserData()
O.startGlowing()


After wizard NPCs were added who have wands and are able to cast spells, so a refactor was in order and "/obj/wand/var/owner" was retyped from "mob/alive/player" to "mob/alive" as NPCs are not players. However, due to size of the codebase, the coder who did the refactor did not notice the fireball spell casting the owner as a player and attempting to call updateUserData(). Due to BYOND blindly accepting typecasts, the refactored code would still compile and work normally, but a runtime would occur when the NPC wizard would attempt to fire a fireball.

Here comes in the auto keyword.

In declaration/initialization shorthand expressions only (ie: var/type/name = value). You would be able to replace type by "auto" and the variable would inherit the type of the initial value. Let's revisit the code example but with the "auto" keyword:


/mob/living/player
name = "player"

/mob/living/player/proc/updateUserData()
//stub
return

/obj/wand
var/mob/living/player/owner

/datum/spell/fireball
var/obj/wand/spellcaster

/datum/spell/fireball/proc/Attack()
var/auto/O = spellcaster.owner
O.health += 15
O.xp += 50
O.updateUserData()
O.startGlowing()


Now when "/obj/wand/var/owner" is retyped to "mob/living". var/O in Attack() would change from being a mob/living/player and inherit the new type of spellcaster.owner which is mob/living. And because updateUserData() exists on mob/living/player and not mob/living. BYOND would refuse to compile and instead throw an undefined var compile error. Avoiding the hard to find runtime error.