Re-evaluate filtering functions

[mikearnaldi]

Filter functions are kind of disaligned between modules and sometimes a bit odd, for example:

import { Effect, Option } from "effect"

const filtered = Effect.filter(
  [0, 1, 2, "ok", "maybe"],
  (v) => v === "nooo" ? Effect.fail(new Error(v)) : Effect.sync(() => typeof v === "number")
)

const filterMapped = Effect.filterMap(
  [Effect.succeed(0), Effect.succeed(1), Effect.succeed(2)],
  (v) => v > 3 ? Option.none() : Option.some(v + 1)
)

I'd expect instead:

import { Effect, Option } from "effect"

const filtered = Effect.filter(
  [0, 1, 2, "ok", "maybe"],
  (v) => v === "nooo" ? Effect.fail(new Error(v)) : Effect.sync(() => typeof v === "number")
)

const filterMapped = Effect.filterMap(
  [0, 1, 2],
  (v) => v > 3 ? Effect.succeed(Option.none()) : Effect.succeed(Option.some(v + 1))
)

[IMax153]

I agree with this 100%. I find the existing Effect.filterMap API strange anyways.

[wbhob]

Seems like there's a matrix of types in/out that can be built:

	boolean OUT	Effect<boolean> OUT
Array IN	Array.filter	Effect.filter
Array<Effect> IN	Effect.filterMap & ignore result	?

and a similar one for filter map

	T OUT	Effect<T> OUT
Array<T> IN	Array.filter().map()	Effect.filter > Effect.flatMap
Array<Effect<T>> IN	Effect.filterMap	?

[mikearnaldi]

Wondering if we shouldn't take a different strategy, I currently see a number of issues:

1. filter can't refine unless for simple scenarios where a Refinement can be supported
2. filterMap is verbose and requires mixing values with options
3. filter + filterMap are kind of variants of the same principle and we are duplicating APIs

I have started playing around with the following idea: https://effect.website/play#b7c0272daa18

It looks to me much less verbose and it allows in one shot to both filter/refine and to map

[mikearnaldi]

I've placed omit inside the filter function to reduce the noise but it could very well be exported from the main effect module and declared in something like Predicate