Backporting from effect/*

[gcanti]

The following features can be backported without breaking changes:

2.14

• flatMap (aka chain / chainW) add flatMap #1849

2.15

• flatMap* (aka chain*K / chain*KW) add more flatMap* dual functions #1862
• tap (aka chainFirst / chainFirstW) add tap #1857
• tapError (aka orElseFirst / orElseFirstW) add tapError #1858
• LazyArg (aka Lazy) add LazyArg #1856

2.16

• tapEither (dual) (aka chainFirstEitherK / chainFirstEitherKW) feat: tapEither #1864
• tapIO (dual) (aka chainFirstIOK) feat: tapIO #1865
• as / asUnit feat: as and asUnit #1867
• tapTask (dual) (aka chainFirstTaskK) feat: tapTask #1869
• mapError (dual) (aka mapLeft) add mapError #1870
• mapBoth (dual) (aka bimap) add mapBoth #1872
• tapReader (dual) (aka chainFirstReaderK / chainFirstIReaderKW) feat: tapReader #1871
• tapReaderEither (dual) (aka chainFirstReaderEitherK / chainFirstEitherKW) Add remaining tap*s #1873
• tapReaderIO (dual) (aka chainFirstReaderIOK) Add remaining tap*s #1873
• tapReaderTask (dual) (aka chainFirstReaderTaskK) Add remaining tap*s #1873
• tapTaskEither (dual) (aka chainFirstTaskEitherK / chainFirstTaskEitherKW) Add remaining tap*s #1873
• flatMapReaderTask (dual) (aka chainReaderTaskK / chainReaderTaskKW) Add ReaderTask, TaskEither and IO flatMaps #1874
• flatMapTaskEither (dual) (aka chainTaskEitherK / chainTaskEitherKW) Add ReaderTask, TaskEither and IO flatMaps #1874
• flatMapIO (dual) (aka chainIOK) Add ReaderTask, TaskEither and IO flatMaps #1874
• Option.orElse (dual) (aka alt / altW) Backport Option.orElse from effect/ #1868
• flatMapTask (dual) (aka chainTaskK) Add flatMapTask & flatMapReader #1876
• flatMapReader (dual) (aka chainReaderK / chainReaderKW) Add flatMapTask & flatMapReader #1876
• flatMapReaderIO (dual) (aka chainReaderIOK / chainReaderIOKW) feat: flatMapReaderIO #1879
• flatMap* (aka chain*K / chain*KW) Add remaining flatMaps #1880

2.17

• asUnit -> asVoid

TODO (Feel free to add a comment to this issue if you want to suggest any other backporting)

• ???

[sukovanej]

What about these.

tap*

• tapEither (chainFirstEitherK / chainFirstEitherKW) feat: tapEither #1864
  • IOEither
  • TaskEither
  • ReaderEither
  • ReaderTaskEither
  • IOOption
  • Option
  • TaskOption
  • StateReaderTaskEither
• tapIO (chainFirstIOK)
  • IOOption
  • Task
  • TaskOption
  • IOEither
  • ReaderIO
  • ReaderTask
  • TaskEither
  • ReaderTaskEither
  • StateReaderTaskEither
• tapReaderEither (chainFirstReaderEitherK / chainFirstEitherKW)
  • ReaderTaskEither
• tapReaderIO (chainFirstReaderIOK)
  • ReaderTask
  • ReaderTaskEither
• tapReader (chainFirstReaderK / chainFirstIReaderKW)
  • ReaderIO
  • ReaderTask
  • ReaderEither
  • ReaderTaskEither
  • StateReaderTaskEither
• tapReaderTask (chainFirstReaderTaskK)
  • ReaderTaskEither
• tapTaskEither (chainFirstTaskEitherK / chainFirstITaskEitherKW)
  • ReaderTaskEither
• tapTask (chainFirstTaskK)
  • TaskOption
  • ReaderTask
  • TaskEither
  • ReaderTaskEither
  • StateReaderTaskEither

tapError* - there are TE.orElseFirstTaskK, TE.orElseFirstIOK and IOE.orElseFirstIOK, would it make sense to add remaining tapError* combinators for types with errors?

[gcanti]

IMO it always makes sense since you get dual APIs and also a better name (tapError vs orElseFirst)

[sukovanej]

as and asUnit would be also nice, hm?

• Either
• IO
• IOEither
• IOOption
• Option
• Reader
• ReaderEither
• ReaderIO
• ReaderTask
• ReaderTaskEither

Does it make sense to implement as and asUnit for any data type having a functor instance or is there rule / law / practical reasoning for not having it for some data types? I see, in the effect/data, it's not implemented for arrays or Identity. What about State for example?

[gcanti]

No, there isn't a specific reason, they just don't seem very useful in the case of ReadonlyArray and Identity

[sukovanej]

Are struct and tuple from Product considered stable enough to be backported?

[gcanti]

Are struct and tuple from Product considered stable enough to be backported?

@sukovanej I think it's better to wait a little longer

p.s.
Anything else you would like to add? otherwise we could release 2.16

[sukovanej]

Ok. I don't have anything right now.

[christophgietl]

How about tap for Identity? For me it feels a little bit awkward to write O.tap and I.chainFirst.

[leighman]

Don't know if you now want to introduce asVoid or whether unit remains the terminology in fp-ts?