What happened?
Record.fromIterableBy is currently data-first only.
With Effect APIs, many functions are dual/curried so they compose naturally in pipe. For fromIterableBy, I can’t do the equivalent data-last style and have to introduce an adapter lambda.
Current (works, but less ergonomic):
pipe(
rows,
(rows) => Record.fromIterableBy(rows, Struct.get("authEmail")),
)
Attempted style (does not type-check):
pipe(
rows,
Record.fromIterableBy(Struct.get("authEmail")),
)
This breaks pipeline readability and consistency with other dual APIs.
Repro context
What would you like?
Add a dual/curried overload for Record.fromIterableBy (and possibly fromIterableWith for consistency):
export declare const fromIterableBy: {
<A, K extends string | symbol>(
f: (a: A) => K,
): (items: Iterable<A>) => Record<ReadonlyRecord.NonLiteralKey<K>, A>
<A, K extends string | symbol>(
items: Iterable<A>,
f: (a: A) => K,
): Record<ReadonlyRecord.NonLiteralKey<K>, A>
}
That would allow:
pipe(rows, Record.fromIterableBy(Struct.get("authEmail")))
Why this matters
This is mostly an ergonomics / consistency improvement, but it also avoids confusing type errors when users assume dual behavior in pipelines.
What happened?
Record.fromIterableByis currently data-first only.With Effect APIs, many functions are dual/curried so they compose naturally in
pipe. ForfromIterableBy, I can’t do the equivalent data-last style and have to introduce an adapter lambda.Current (works, but less ergonomic):
Attempted style (does not type-check):
This breaks pipeline readability and consistency with other dual APIs.
Repro context
3.19.3What would you like?
Add a dual/curried overload for
Record.fromIterableBy(and possiblyfromIterableWithfor consistency):That would allow:
Why this matters
This is mostly an ergonomics / consistency improvement, but it also avoids confusing type errors when users assume dual behavior in pipelines.