Giulio Canti

So the input schema is something along the lines of ```ts // --------------------------- // input schema // --------------------------- type InputKey = Record interface LongKey extends InputKey {} interface RaDecKey extends...

@kpritam you are right, `DomainParam` ```ts const DomainParam = D.union( DomainLongKey, DomainRaDecKey, DomainFloatKey, DomainStructKey, DomainBooleanKey, DomainByteKey ) ``` can be optimized

@twop it would be nice having a static exhaustivity check, what if you can call `exhaustive` only if you can prove you handled all cases? ```ts export class Match {...

@twop Guards / refinements look unsafe though, cfr. with "manual pattern matching" ```ts const value: string | number = 1 as any const x = match(value)() .case(isString, s => s.length)...

In the experimental module `Decoder` I came up with an agnostic API `refine` ```ts import { Refinement } from 'fp-ts/function' export declare const refine: ( refinement: Refinement, // a is...

> the only difference there is P extends t.AnyProps instead of This looks unsafe, example: ```ts import { Either } from 'fp-ts/Either' import * as t from 'io-ts' export const...

@jonball4 could you please provide a repro?

> As far as I can see right now, your approach requires full coverage of possible status codes You can handle as many status codes as you wish (full or...

> Such approach allows even greater API discoverability I agree, chainable APIs are nice for API discoverability, but there's no need for better discoverability with an API like `make`: configuration...

> As handlers now work with a raw response, the `Decorder` is `ReaderTaskEither` :+1: much better > onUnexpectedError is ReaderTaskEither Looks like `JsonDeserializationError` is unused now, what about `onUnexpectedError: Decoder`?...