Task.wait(n) vs wait(n)

I’ve heard a lot of people say to use task.wait(n) instead of wait(n). Is there any situations where you would use wait(n) over task.wait(n) or is task.wait(n) just definitively better? Any help is appreciated.

8 Likes

I can’t think of a situation where you’d want to use wait() over task.wait()

3 Likes

No. Definitively not, task.wait is definitively better.

The differences with wait and task.wait are:

  • wait() can sometimes delay when it resumes the thread because of performance concerns, which is actually bad because you will rarely have those because of it

  • task.wait() updates 2x faster than wait(), therefore more accurate

Also:

Just note that task.wait, just like wait is still a code smell, usually indicates a bigger structural problem with your code.

34 Likes

wait() also returns a second value which describes the time that it finished yielding (basically os.time()). An example of this can be found in the Roblox default animate script. Note that it’s not worth using wait() over task.wait() specifically for this reason. You can simply call os.time after your yield to replicate the behavior.

3 Likes

task.wait(...) is based off of RunService.Heartbeat meaning that task.wait(...) is == RunService.Heartbeat. If you add parameters, it will keep yielding RunService.Heartbeat until the number you replace with ...'s time is up. Idk how wait works, but DONT USE IT. It is old, legacy, and will become deprecated soon.

3 Likes

Thanks for the help you guys! If anybody else wants to add more info, feel free to do so.

1 Like

Just wanted to chime in and say that while we haven’t deprecated wait yet we intend to do so in the future. That’s not to say it will stop working, just that you should use task.wait going forward.

35 Likes

Oh I thought you meant you’d remove wait() one day.

5 Likes

He said in his post:

5 Likes