Update task.yaml

[lack-of-gravity-jack]

Changes

common misconception is that people think defer "defers" to a later frame

Checks

By submitting your pull request for review, you agree to the following:

• [ x] This contribution was created in whole or in part by me, and I have the right to submit it under the terms of this repository's open source licenses.
• [x ] I understand and agree that this contribution and a record of it are public, maintained indefinitely, and may be redistributed under the terms of this repository's open source licenses.
• [x ] To the best of my knowledge, all proposed changes are accurate.

[ownerofclassicobby]

Changes

common misconception is that people think defer "defers" to a later frame

Checks

By submitting your pull request for review, you agree to the following:

• [ x] This contribution was created in whole or in part by me, and I have the right to submit it under the terms of this repository's open source licenses.
• [x ] I understand and agree that this contribution and a record of it are public, maintained indefinitely, and may be redistributed under the terms of this repository's open source licenses.
• [x ] To the best of my knowledge, all proposed changes are accurate.

Thanks you have permission to code and add updates

[IgnisRBX]

Hi @lack-of-gravity-jack,
I checked with engineering and they'd like to clarify but simplify task.defer() to this:

Accepts a function or a thread (as returned by Library.coroutine.create()) and defers it until the end of the current resume point within the current frame.

I also made a bunch of small edits to fix minor grammar and un-linked APIs.

[lack-of-gravity-jack]

Looks good to me

I noticed references to fastSpawn in task.spawn section. I personally didn't know what fast spawn was and after looking around a bit, it seems like a workaround to the legacy spawn()'s yielding behavior, to get a new thread to run instantaneously using bindables (this may be incorrect). I feel like this tidbit is unnecessarily confusing to leave in there now that there's been no reason to use this fastSpawn pattern for many years. Also, I don't believe the fastspawn pattern would even work anymore since events are deferred

the bit about task.spawn not being a replacement for legacy spawn can be clarified instead as
"Unlike the deprecated global spawn() function, this function resumes the accepted function/thread immediately"

[IgnisRBX]

Good call on researching the fastSpawn bit and flagging for removal (I did so). And I'll just let the intro paragraph for task.spawn() speak for itself instead of drawing relation to the deprecated spawn() function. Thanks again for your contributions!