I TAd a CS101 course in grad school. I saw a number of students try do something like this:

  func(if(x == 5) foo else bar)

In other words, treating an "if...else" statement as something that can be reduced to a value. This frustrated the students because it did not compile. We had to train them to think in terms of sequential execution, despite the fact that they did not become any better at programming in the process (worse, they had to un-learn a perfectly valid way to think about programming -- only to have to re-learn it later if they took the programming languages course).

What language was your class using? There are so many ways to do what the students wanted to do, be it the tertiary function or a lambda function or even, defining a method/function like (Ruby):

  def foowiz(x, threshold = 5)

    if x == threshold

      foo

    else

      bar

    end

  end

And then a call to func(foowiz(x)) would work - even in an OOP language like Ruby.

What did the students need to unlearn?

In the intro CS class I took an age ago, we had to implement OOP as a final assignment in Dr. Scheme, which is a derivative of LISP that is most assuredly a functional language rather than OOP. That did not mean I had to unlearn how lambdas and tail recursion worked.

Why did they have to "un-learn" anything? What they should learn from that experience is that the particular tool they were using did not have a feature they expected. Any reasonable teacher should explain that. It's important because often, extra features come at a cost and while some of those costs have been paid permanently by researchers and software developers of the past, others still require tradeoffs.

Thinking in abstract terms is all well and good until you actually have to run code in a real environment to solve a real problem with the tools you have available.

Well, in C you can definitely do that:

return (x == 5) ? foo : bar;