Scala：向高阶函数传递不纯函数是否符合函数式编程规范？

Great question—this is a super common point of confusion when switching between imperative and functional styles in Scala, so let’s break it down clearly.

Core Verdict #

In strict functional programming (FP) principles, this pattern is not considered acceptable, but it’s a frequent "pragmatic shortcut" in Scala’s multi-paradigm ecosystem. That said, there are far better, more idiomatic alternatives that align with FP values.

Why this violates FP principles #

Functional programming hinges on semantic clarity and explicit management of side effects. Here’s why this map usage misses the mark:

• The core purpose of map is to transform elements of a collection and produce a new, meaningful collection. When you pass a function that returns Unit, you end up with a List[Unit]—a collection of nothing but () values, which has zero practical utility.
• You’re essentially hijacking map’s traversal mechanism to execute side effects (like printing to console, modifying external state, or writing to a database). This misrepresents code intent: other developers seeing map will assume you’re transforming data, not running hidden actions.
• Strict FP requires that side effects are encapsulated (e.g., in an IO monad) rather than executed "under the hood" within a transformation function.

Why you might see this in Scala code #

Scala is a multi-paradigm language, so many developers blend functional and imperative styles. map is a familiar method for iterating over collections, so some folks reach for it out of habit instead of using the right tool for the job. It works, but it’s not idiomatic.

Idiomatic alternatives for FP and Scala #

If you need to execute side effects on each element of a collection, here are the better options:

• Use foreach: This is Scala’s dedicated method for iterating over a collection to run side effects. Its semantics are crystal clear—anyone reading myList.foreach(item => someImpureFunction(item)) immediately knows you’re performing actions on each element, not transforming data. This is the go-to choice for most imperative-style side effect use cases in Scala.
• Encapsulate side effects with an IO monad (strict FP): For pure functional codebases, wrap your impure function in an IO type (from libraries like Cats Effect or ZIO). Then use traverse to handle the collection, which keeps side effects explicit and manageable:

  import cats.effect.IO
  
  val effects: List[IO[Unit]] = myList.map(item => IO(someImpureFunction(item)))
  val combinedEffect: IO[List[Unit]] = IO.traverse(effects)(identity)
  // Run the effect safely in your application's entry point
  combinedEffect.unsafeRunSync()
  

  This approach aligns with FP’s requirement that side effects are first-class values, not hidden actions.
• Use tap (for chained operations): If you need to run a side effect in the middle of a chain of transformations without discarding the original collection, Scala 2.13+ provides tap, which executes a function on each element and returns the original element (avoiding the useless List[Unit]):

  myList.tap(item => someImpureFunction(item))
  

  This is still for side effects, but it’s more semantically honest than misusing map.

Final Takeaway #

While Scala allows this map + Unit pattern, it’s a misapplication of FP principles and harms code readability. Stick to foreach for straightforward side effect iteration, or use IO monads if you’re working in a strictly functional codebase.

内容的提问来源于stack exchange，提问作者Mandroid