"waitfor is now obsolete"

ID:2176100
 
Nov 22 2016, 11:27 am
BYOND Version:511.1363
Operating System:Windows 10 Home 64-bit
Web Browser:Chrome 54.0.2840.99
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
I don't have a use case for this. I just noticed the funny warning.
world
    mob = /mob/player

mob
    Login()
        src << "start"
        A()
        src << "finish"
    
    proc
        A()
            set waitfor = FALSE
    
    player
        A()
            // waitfor is inherited as FALSE, 
            set waitfor = TRUE // made apparent by removing this line
            sleep 10
            world << "child"


Expected: No compiler warning.

Actual: "warning: =: waitfor is now obsolete, since it is the default behavior"

"waitfor = TRUE" may be default behavior, but it's not the inherited behavior of player.A(), so it's not redundant.

Also, some of us don't believe that waitfor is obsolete, since spawn isn't much better in most cases.
Nov 22 2016, 12:44 pm
It's waitfor=1 that's obsolete, not waitfor=0. I should change the warning message, but it's basically warning you that the behavior you're specifying is the default. (For the record, I don't intend to ever drop waitfor=0 support.)

However I believe you're incorrect about inheritance. I don't think mob/player/A() is meant to inherit waitfor from mob/A().
Nov 22 2016, 12:49 pm
Whether it's meant to or not, it does. I didn't think it did either, but I tested it and waitfor does get inherited.
Nov 22 2016, 7:47 pm
This inheritance is pretty widely depended upon at /tg/station.

This is why they think the warning is out of place, setting a waitfor = 0 proc back to waitfor = 1 shouldn't trigger a warning.
Nov 22 2016, 8:26 pm
I'll have to take a look and see if I can figure out how the inheritance is setup. I agree it shouldn't deliver a warning in this circumstance, although I don't know if it's feasible for the compiler to look at the parent proc at the point where that's generated.