El dicho «push ifs up and fors down» proviene del documento Tiger Style de TigerBeetle y ha sido discutido por desarrolladores como matklad y Debasish Ghosh. Su principio central es centralizar el flujo de control moviendo las sentencias condicionales (if) hacia el exterior, hacia el llamador o más temprano en una tubería de procesamiento de datos, mientras reubica los bucles iterativos (for) hacia el interior, hacia etapas posteriores donde los datos pueden procesarse en lotes. Esta separación pretende simplificar las funciones al hacer explícitas sus precondiciones en sus tipos y permitir que los bucles críticos se ejecuten sin ramas, lo que mejora la claridad y el rendimiento.
En la práctica, empujar los condicionales hacia arriba significa transformar una función que verifica internamente entradas inválidas (como None en un tipo Option) en una donde el llamador maneja esos casos y la función asume entrada válida. Por ejemplo, una función `frobnicate(walrus: Option<Walrus>)` que verifica None internamente puede cambiarse de modo que el llamador filtre los valores None y pase un `Vec<Walrus>` a `frobnicate_batch`, que luego procesa el lote sin ninguna verificación condicional. De manera análoga, empujar los bucles hacia abajo implica reemplazar un bucle que llama a una función escalar por elemento con una función por lotes que procesa toda la colección, permitiendo amortizar los costos de arranque y ofrecer oportunidades de vectorización. La base algebraica de tales transformaciones se ilustra con la equivalencia filter-map: `filter p . map f == map f . filter (p . f)`, que se cumple gracias a la naturalidad de `catMaybes` y ahorra trabajo cuando `p . f` se reduce a un predicado barato sobre los datos de entrada.
Sin embargo, el dicho no es universalmente aplicable. Mover un condicional fuera de un bucle es válido solo cuando la condición es invariante en el bucle; de lo contrario, la decisión debe permanecer donde varía los datos. Empujar una selección por debajo de un join en la optimización de consultas de base de datos es seguro solo cuando el predicado hace referencia a columnas de un solo lado del join, garantizando que la semántica del join permanezca sin cambios. Del mismo modo, la reescritura filter-map ahorra cálculo solo cuando `p . f` se simplifica a un predicado barato sobre la entrada cruda, ya que en caso contrario la forma reescrita todavía calcula `f` para cada elemento antes de probar. Por lo tanto, la eficacia del dicho depende de reconocer propiedades algebraicas —como la inclusión de monomorfismo o la naturalidad— que garanticen que la transformación preserva el significado mientras potencialmente reduce el costo.