StartCoroutine(Fade) vs just calling Fade() as a normal function

If we use Fade() instead of StartCoroutine(Fade), does that mean that it will not be returning an ienumerator and just run like a normal function?

Generally speaking, you can’t call a coroutine like you would a method.

public IEnumerator FadeOut(float time)
        {
            return Fade(1, time);
        }

Isn’t that what happened here? Fade() is a coroutine with return type IEnnumerator. But we didn’t do StartCoroutine(Fade). We just called it like a normal function.
Is my understanding wrong?

If you can call an IEnumerator without using StartCoroutine from within an IEnumerator, that’s news to me, and even if you can, it’s not exactly a good way to go about it. If anyone else needs to look over the code, it’s going to unnecessarily obscure what’s being called.

An IEnumerator from an IEnumerator isn’t really “general” usage as Coroutines is Unity hacking the C# language to do things over time. IEnumerators are generally used to iterate over lists.

Your understanding may be right. It’s not something that I’d plug into code to test out.

It’s only because Fade() is a coroutine that we can do this particular construction, and while it’s taught in the course, I tend to agree that this one got a bit into the weeds. We’re doing this, however, to solve a particular problem, in that if both Coroutines run at the same time, the fader will freeze. In order to stop a particular coroutine, you need a link to it, and this method helps us accomplish that task, in a sort of variation of our IAction pattern used earlier in the course.

If you were to try to return anything other than a Coroutine, a simple return would not even compile.

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.

Privacy & Terms