Backporting from effect/*

[gcanti]

The following features can be backported without breaking changes:

2.14

• flatMap (aka chain / chainW) https://github.com/gcanti/fp-ts/pull/1849

2.15

• flatMap* (aka chain*K / chain*KW) https://github.com/gcanti/fp-ts/pull/1862
• tap (aka chainFirst / chainFirstW) https://github.com/gcanti/fp-ts/pull/1857
• tapError (aka orElseFirst / orElseFirstW) https://github.com/gcanti/fp-ts/pull/1858
• LazyArg (aka Lazy) https://github.com/gcanti/fp-ts/pull/1856

2.16

• tapEither (dual) (aka chainFirstEitherK / chainFirstEitherKW) https://github.com/gcanti/fp-ts/pull/1864
• tapIO (dual) (aka chainFirstIOK) https://github.com/gcanti/fp-ts/pull/1865
• as / asUnit https://github.com/gcanti/fp-ts/pull/1867
• tapTask (dual) (aka chainFirstTaskK) https://github.com/gcanti/fp-ts/pull/1869
• mapError (dual) (aka mapLeft) https://github.com/gcanti/fp-ts/pull/1870
• mapBoth (dual) (aka bimap) https://github.com/gcanti/fp-ts/pull/1872
• tapReader (dual) (aka chainFirstReaderK / chainFirstIReaderKW) https://github.com/gcanti/fp-ts/pull/1871
• tapReaderEither (dual) (aka chainFirstReaderEitherK / chainFirstEitherKW) https://github.com/gcanti/fp-ts/pull/1873
• tapReaderIO (dual) (aka chainFirstReaderIOK) https://github.com/gcanti/fp-ts/pull/1873
• tapReaderTask (dual) (aka chainFirstReaderTaskK) https://github.com/gcanti/fp-ts/pull/1873
• tapTaskEither (dual) (aka chainFirstTaskEitherK / chainFirstTaskEitherKW) https://github.com/gcanti/fp-ts/pull/1873
• flatMapReaderTask (dual) (aka chainReaderTaskK / chainReaderTaskKW) https://github.com/gcanti/fp-ts/pull/1874
• flatMapTaskEither (dual) (aka chainTaskEitherK / chainTaskEitherKW) https://github.com/gcanti/fp-ts/pull/1874
• flatMapIO (dual) (aka chainIOK) https://github.com/gcanti/fp-ts/pull/1874
• Option.orElse (dual) (aka alt / altW) https://github.com/gcanti/fp-ts/pull/1868
• flatMapTask (dual) (aka chainTaskK) https://github.com/gcanti/fp-ts/pull/1876
• flatMapReader (dual) (aka chainReaderK / chainReaderKW) https://github.com/gcanti/fp-ts/pull/1876
• flatMapReaderIO (dual) (aka chainReaderIOK / chainReaderIOKW) https://github.com/gcanti/fp-ts/pull/1879
• flatMap* (aka chain*K / chain*KW) https://github.com/gcanti/fp-ts/pull/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) #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?